Re: ROM adventures
Posted: 12 Feb 2023, 22:17
The v6— option worked fine for me - thank you !
A place for Gigatron builders and hackers
https://forum.gigatron.io/
Code: Select all
% glcc -rom=dev7 -map=128k,./mscp.ovl mscp.o core.o onload.s -o mscp_128k.gt1
% python3 addbook.py mscp_128k.gt1 book.bin
Code: Select all
% glcc -rom=dev7 -map=512k,hr,./mscp.ovl mscp.o core.o onload.s -o mscp_512k_hr.gt1
% python3 addbook.py mscp_512k_hr.gt1 book.bin
Code: Select all
0301 NEXT: adda([vTicks]) # Count elapsed time
0302 blt('EXIT') # Branch away when there is not enough time left for the next opcode
0303 st([vTicks]) # Delay slot: store updated time
... # Advance program counter
0307 ld([Y,X]) # Fetch opcode
---
0309 bra(AC) # Branch to opcode implementation
030a ld([Y,X]) # Delay slot: fetch opcode argument
030b EXIT: ... # Resynchronize and return to video code
Code: Select all
1401 NEXT: adda([vTicks]) # Count elapsed time
1402 bge([fsmState]) # Branch to native code block if enough time left
1403 st([vTicks]) # Delay slot: store updated time
1404 EXIT: ... # Resynchronize and return to video code
This code is now substantially faster in ways that would have been very complicated to program as a self-restarting SYS call.lb3361 wrote: ↑01 Dec 2022, 16:12 Hello Ari and Hans,
I tried to estimate the hidden cost of dispatching long instructions and found that it increases very quickly after 64 cycles. Splitting them into independently scheduled pieces is penalized by the dispatching cost (15 to 20 cycles, depending how you count) and is also very complex. At some point I stumbled on a very fast way to write a dispatcher as a finite state machine. It only has the minimal set of entry points, ENTER and NEXT. Everything has to be in one page. But the overhead is only 3 cycles (or 5 if you count the jump to NEXT)
...
I tried to apply this to AT67's SYS_Multiply_s16 and SYS_Divide_s16. You can see the code at https://github.com/lb3361/gigatron-rom/ ... m.py#L6061. Instead of executing the multiplication as 16 fragments of 56-66 cycles, it does so as 34 fragments which are all less then 28 cycles. The division is even more extreme: 49 fragments. Other than that, this is basically AT67's code. Here are the timing results for 3000 16x16 multiplications with semi-random argumentsNot only this saves time, but it is also far easier to program. Since each fragment starts at cycle 3, one can write a surprising amount in 28 cycles. In addition, there is little need to make complicated adjustments when one merges two control paths with different execution time. One can always branch to NEXT and be done with it. This of course has a lot of consequences on how to program long opcodes.Code: Select all
+----------+----------+----------+ | vCPU | Native | FSM | +----------------------------+----------+----------+----------+ | 3000 multiplications 16x16 | 12.6 | 4.15 | 3.42 | | 3000 divisions 16/16 | 15.4 | 7.45 | 4.93 | +----------------------------+----------+----------+----------+
Code: Select all
+----------+----------+----------+----------+
| vCPU | Native | FSM | Newest |
+----------------------------+----------+----------+----------+----------+
| 3000 multiplications 16x16 | 12.6 | 4.15 | 3.42 | 2.75 |
| 3000 divisions 16/16 | 15.4 | 7.45 | 4.93 | 4.93 |
+----------------------------+----------+----------+----------+----------+
The FSM in page 1500 implements micro-opcodes and programs both SYS_Exec and SYS_Loaders in terms of these micro-opcodes. You can see the micro-programs at https://github.com/lb3361/gigatron-rom/ ... m.py#L6996 and https://github.com/lb3361/gigatron-rom/ ... m.py#L7082. Most of the micro-opcodes resemble vCPU operations and are shared by both SYS calls, some perform tasks that are very specific to SYS_Exec or SYS_Loader such as uLUP, uSERIN, uDAT. Anyway, something that was rather difficult to code turned into something considerably easier to program and debug.lb3361 wrote: ↑01 Dec 2022, 16:12 But there is more. One of my goals was to rewrite sys_Exec in purely native code because the v5a one uses memory on the stack, and I have other plans for the stack. The idea was to use the same scheduler but use fsmState as a program counter. Therefore I write a bunch of microinstructions and a program that uses them. You can see that at https://github.com/lb3361/gigatron-rom/ ... m.py#L6263. Then I realized that I could also write a native Loader that shares most of its code with the native Exec. I did not test this thoroughly because I do not have the right setup (my Arduino has long been repurposed). But I find this appealing.
Come on dude, I've asked multiple times now, just let it go. I'm not interested in your passive aggressive nonsense.lb3361 wrote: ↑02 Mar 2023, 22:14 I got very excited and decided to share it immediately with Hans61 and at67 because I see that it offers a lot of potential for constructing native support for rich graphics capabilities, something of great interest to at67. I believe he saw competition rather than contribution.
It is true that I had no intention to produce a ROM. In fact I was totally disgusted. Then I got Covid over Xmas, got bored, started to code something to play mscp on a 128k gigatron, then added opcodes, then revived my floating point ideas, etc. All things I would have been glad to do for ROMvX0 in fact if you had not made clear that you do not want it. Competition is a self-fulfilling prophecy. In the end I don't regret because one should never yield to the bully.at67 wrote: ↑03 Mar 2023, 09:12 And for the record after you showed me this new stuff, (which is great btw), you said you would not create a competing ROM, but within weeks you had. The reason "I saw competition" is because you created it and then started flaunting it, remember this comment "well what are you going to do with ROMvX0 now?"
I'm the bully and you're the victim genius, lets just leave it at that then.lb3361 wrote: ↑04 Mar 2023, 00:17It is true that I had no intention to produce a ROM. In fact I was totally disgusted. Then I got Covid over Xmas, got bored, started to code something to play mscp on a 128k gigatron, then added opcodes, then revived my floating point ideas, etc. All things I would have been glad to do for ROMvX0 in fact if you had not made clear that you do not want it. Competition is a self-fulfilling prophecy. In the end I don't regret because one should never yield to the bully.at67 wrote: ↑03 Mar 2023, 09:12 And for the record after you showed me this new stuff, (which is great btw), you said you would not create a competing ROM, but within weeks you had. The reason "I saw competition" is because you created it and then started flaunting it, remember this comment "well what are you going to do with ROMvX0 now?"
So the ROM is here and shows what can be done. I do not have great plans going forward. So feel free to copy the good ideas and make your dream graphic machine. Or feel free to try to ignore it while knowing that it shows how things can be done better.
And don't get me wrong: I actually hoped to find an outcome you would have liked. Maybe I touched something painful without knowing. Anyway, now the dev7 rom exists and does what it advertises. It is more a demonstration than a finished product. So feel free to copy (and most likely improve) the good bits while making your dream graphic machine. Btw the way you implement sprites in romvx0 is very smart (I actually have a lot of respect for your work, believe it or not.)at67 wrote: ↑11 Dec 2022, 21:00Ok, wow, this changes everything, I didn't realise my happiness was such a high priority.
Given the above, I now revert all previous permissions I have given you, this applies to all code I have written, (but not limited to), Native, (ROM), vCPU, gtBASIC, GCL, gtBASIC runtime, applications, games, tests...I think you get the idea. So that means no SDCARD Browser, Tetronis, Invader, ROM routines lifted from ROMvX0, etc, should find their way into ROMv5, ROMv6, or any ROM's that you work on.
For bonus happiness points, it would be awesome if you gave me permission to remove what little code you contributed to ROMvX0, so that I could have a clean slate while we have two diverging ROM paths. Obviously I don't need your permission to remove your code from my ROM, but I guess respect is something I strive to give and receive.