2 ms·

Be cool to see the source - I assume he wrote it in assembler?

by rwmj 4y ago

GlassTTY 4y ago
Hi, glad you like the vid etc. and thanks for the nice comments. Unfortunately I don't think I can share the code due one small, albeit essential, bit that I think may have interlectual property attached to it (I never did find out for sure). Think of it as a constant that keeps the model running except its not a constant. I am not a nuclear physicist but out son is (he designs reactor cores), he helped me to understand some of the maths. The ZX81 code does model the various interactions in tempreture, radioactivity etc. and remarkably, once the code snippet mentioned above was added the model moves quickly to criticality and returns again after a rod change etc. I couldn't quite believe it really. However, once this was achieved in go (golang), I just ported it to C and used Z88DK to target a ZX81.
gus_massa 4y ago
Quoting one comment of the author: > I wrote the model in Go first and once that was working I converted it to C which very straight forward. Once in C I used Z88DK as the compiler, this comes with tools to create a zx81 application. The IDE was VSCode running on a Mac with a few scripts to build and launch the Clock Signal ZX81 Emulator for testing before creating a tzxduino file. I think I detailed it on https://glasstty.com https://glasstty.com . > I use the same environment for writing nascom stuff. Its more straight forward than it sounds.
- rwmj 4y ago
  [I wrote a comment about my half-remembered experiences writing C code for Z80 back in the 1980s, and how compilers didn't do very well, but deleted it because these links summarise the situation much better. In particular it looks like Z88DK solves the problems I was having (if only it existed back then ...)] https://retrocomputing.stackexchange.com/questions/6095/why-do-c-to-z80-compilers-produce-poor-code https://retrocomputing.stackexchange.com/questions/6095/why-... https://retrocomputing.stackexchange.com/a/4924 https://retrocomputing.stackexchange.com/a/4924

Be cool to see the source - I assume he wrote it in assembler?

by rwmj 4y ago

Be cool to see the source - I assume he wrote it in assembler?

Hi, glad you like the vid etc. and thanks for the nice comments. Unfortunately I don't think I can share the code due one small, albeit essential, bit that I think may have interlectual property attached to it (I never did find out for sure). Think of it as a constant that keeps the model running except its not a constant. I am not a nuclear physicist but out son is (he designs reactor cores), he helped me to understand some of the maths. The ZX81 code does model the various interactions in tempreture, radioactivity etc. and remarkably, once the code snippet mentioned above was added the model moves quickly to criticality and returns again after a rod change etc. I couldn't quite believe it really. However, once this was achieved in go (golang), I just ported it to C and used Z88DK to target a ZX81.

gus_massa 4y ago

Quoting one comment of the author: > I wrote the model in Go first and once that was working I converted it to C which very straight forward. Once in C I used Z88DK as the compiler, this comes with tools to create a zx81 application. The IDE was VSCode running on a Mac with a few scripts to build and launch the Clock Signal ZX81 Emulator for testing before creating a tzxduino file. I think I detailed it on https://glasstty.com https://glasstty.com . > I use the same environment for writing nascom stuff. Its more straight forward than it sounds.

rwmj 4y ago
[I wrote a comment about my half-remembered experiences writing C code for Z80 back in the 1980s, and how compilers didn't do very well, but deleted it because these links summarise the situation much better. In particular it looks like Z88DK solves the problems I was having (if only it existed back then ...)] https://retrocomputing.stackexchange.com/questions/6095/why-do-c-to-z80-compilers-produce-poor-code https://retrocomputing.stackexchange.com/questions/6095/why-... https://retrocomputing.stackexchange.com/a/4924 https://retrocomputing.stackexchange.com/a/4924