ROMv5 ?

Using, learning, programming and modding the Gigatron and anything related.
Forum rules
Be nice. No drama.
lb3361
Posts: 249
Joined: 17 Feb 2021, 23:07

ROMv5 ?

Post by lb3361 »

I believe it is time to consider the release of a true ROMv5 because most of what Marcel has envisioned for ROMv5 has been achieved (see https://github.com/kervinck/gigatron-ro ... asm.py#L91 and compare with https://github.com/kervinck/gigatron-ro ... sm.py#L111. The biggest issue left by Marcel was supporting the RAM & IO expansion with SPI-based SD cards. The three remaining items in this list are:
  1. Reduce the Pictures application ROM footprint. I believe that we should simply drop the Pictures application and use the space for Invaders.gt1 and the Pluggy SD Card browser. Compressing such low resolution pictures will not work great anyway.
  2. Main: Some startup logo as intro, eg. gigatron letters from the box. Any takers?
  3. Loader: make noise while loading (only channel 1 is safe to use). This would increase the RAM footprint of the loader and increase the potential for conflicting gt1 files. What is needed is a loader that is entirely native and does not use RAM space. AT67 has such a loader in his ROMvX0. Therefore this is best left for the future.
  4. Faster SYS_Exec_88, with start address (GT1)?. Same problem as the loader. I have a working one, to be described in a future post. But including such a big change means taking a risk. My preference would be to add this into the new dev rom.
  5. Let SYS_Exec_88 clear channelMask when loading into live channels. This is incorrectly marked as done. It works in the Loader only. Therefore we might need the new sys_Exec after all.
The logistics for releasing a new ROMv5 is quite simple but error prone. One needs to edit dev.asm.py and replace all DEVROM references to v5. One needs to update romTypeValue and update interface.json. One also needs to make a frozen copy of all the application (with a vX suffix) and use that. Then make a copy of this as a new dev rom. I could first stage this on my github copy of the gigatron-rom repository, then, after one month of thesting time, send a pull request with the update. Did I forget something?

But before doing this, there are a number of questions that are best answered by the community.
  • Is there agreement on the idea of releasing a ROMv5 at this point?
  • How should it be called: ROMv5? ROMv5b?
  • If called ROMv5, how to make sure that people understand that 5 > 5a? Should we remove the binaries for ROMv5a (but leave the possibility to rebuild them in the Makefile)?
  • Should we allocate a new romTypeValue (0x40 for ROMv5a, 0x48 for ROMv5?). This is probably related to the previous answer because, if we keep ROMv5a as a full fledged past rom, we need to be able to differentiate them in code. If we don't, then we might still like to be able to differentiate them in code. And all this has to go into the interface.json file.
  • And the big question: Which selection of applications should we include? My preference would be to remove "Pictures" and add AT67's excellent "Invaders" as well as a user-friendly version of the pluggy reloaded browser. This requires adding a new line in the Main Menu. Any other ideas?
walter
Site Admin
Posts: 149
Joined: 13 May 2018, 08:00

Re: ROMv5 ?

Post by walter »

lb3361 wrote: 30 Nov 2022, 16:50 But before doing this, there are a number of questions that are best answered by the community.
  • Is there agreement on the idea of releasing a ROMv5 at this point?
There's enough that's happened to the ROM to release a stable version.
lb3361 wrote: 30 Nov 2022, 16:50
  • How should it be called: ROMv5? ROMv5b?
I'd call it either ROMv5 or ROMv6.
lb3361 wrote: 30 Nov 2022, 16:50
  • If called ROMv5, how to make sure that people understand that 5 > 5a? Should we remove the binaries for ROMv5a (but leave the possibility to rebuild them in the Makefile)?
That's just the marketing side of it :) A sticky note on the forum, post on the main site etc. can go a long way I think.
lb3361 wrote: 30 Nov 2022, 16:50
  • Should we allocate a new romTypeValue (0x40 for ROMv5a, 0x48 for ROMv5?). This is probably related to the previous answer because, if we keep ROMv5a as a full fledged past rom, we need to be able to differentiate them in code. If we don't, then we might still like to be able to differentiate them in code. And all this has to go into the interface.json file.
If the new ROM is so far from the development ROM that we would need to bump the romTypeValue, doesn't it make sense to call it ROMv6? I can live with ROMv5 being available as a development version only. This will automatically solve the issue that people do not know v6 is the latest. Also it is a clean cut from supplied vs community ROM.
lb3361 wrote: 30 Nov 2022, 16:50
  • And the big question: Which selection of applications should we include? My preference would be to remove "Pictures" and add AT67's excellent "Invaders" as well as a user-friendly version of the pluggy reloaded browser. This requires adding a new line in the Main Menu. Any other ideas?
Sad to see the pictures go, but they take an awful lot of space so it is logical they need to go. Invaders would certainly be a nice addition!
qwertyface
Posts: 64
Joined: 16 Jul 2019, 09:19
Location: UK

Re: ROMv5 ?

Post by qwertyface »

Hi, I support the idea that we should be working towards a new release, and think I agree that v6 is the right version to use.

I'm fine with removing pictures, and adding other applications. But I wonder if perhaps we should switch making the version a label for a core set of functionality (fonts and other tables, vCPU features, SYS functions, etc.) and allowing end-users to choose their apps when they burn their ROM. I'm assuming that no one is going to be making a ton of them and selling them.

On my own behalf, I'd quite like to get a SYS_MultiplyBytes into a future ROM version.
veekoo
Posts: 92
Joined: 07 Jun 2021, 07:07

Re: ROMv5 ?

Post by veekoo »

Hello, I also support new stable release. Name could be v5, because v5a is like alpha and v5 is the stable release.

Pictures feature should be replaced with a game; invaders or pucmon.

How is Pluggy Reloaded, does it work then with new release?
lb3361
Posts: 249
Joined: 17 Feb 2021, 23:07

Re: ROMv5 ?

Post by lb3361 »

qwertyface wrote: 02 Dec 2022, 16:11 On my own behalf, I'd quite like to get a SYS_MultiplyBytes into a future ROM version.
There is already a SYS_Multiply_s16, written by at67, that multiplies two 16 bits numbers, returning the low 16 bits of the result. Of course one could improve its implementation in the future to make it much faster.
qwertyface
Posts: 64
Joined: 16 Jul 2019, 09:19
Location: UK

Re: ROMv5 ?

Post by qwertyface »

lb3361 wrote: 05 Dec 2022, 20:43 There is already a SYS_Multiply_s16, written by at67, that multiplies two 16 bits numbers, returning the low 16 bits of the result. Of course one could improve its implementation in the future to make it much faster.
Oh, right. I hadn't noticed that going in.

I don't think my most recent bytes version would be easily extended to larger sizes (for reasons of code space, and the fact that it needs a lot of scratch storage), but I think it could be a lot faster for multiplying small values. I'm hopeful I could fit a self-restarting unsigned 8-bit by 8-bit multiplication, and an unsigned 8-bit square function in a single page, but it's a bit tricky packing the code around the lookup tables, and it does need to have a whole page. The runtime for the multiplication is 119 cycles (before SYS function overhead). I've not got a good feel for how the timings play out in reality, but I reckon if it were split in three roughly equal parts, you'd probably expect it to usually be done within two scanlines, with a fairly low stall expected.

I think it also serves as an interesting example of Gigatron programming (not necessarily one you'd want to follow, but interesting anyway).

If you and the rest of the community would be interested in considering it for the next version of the ROM I can probably make the time to convert it to a SYS function. It might not be a suitable replacement for at67's code, we'd probably want both.
lb3361
Posts: 249
Joined: 17 Feb 2021, 23:07

Re: ROMv5 ?

Post by lb3361 »

veekoo wrote: 04 Dec 2022, 06:21 How is Pluggy Reloaded, does it work then with new release?
It certainly works with the current dev rom. Since this is a popular add-on, it would make sense to have a version of the browser in the ROM. I believe one needs a version that fails more gracefully in the absence of a Pluggy Reloaded.
at67
Posts: 553
Joined: 14 May 2018, 08:29

Re: ROMv5 ?

Post by at67 »

My 2 cents:

Marcel had some strict requirements for official ROM's, 100% SW compatibility, future extensions, etc, which can be gleaned from the source code and documentation .

Marcel also had plans for ROMv5 and ROMv6 stable and and you can in fact get the gist of them by looking at the DEVROM/ROMv5a source code, i.e.

Code: Select all

#  Ideas for ROM v5:
#  DONE v6502: Test with VTL02
#  DONE v6502: Test with Microchess
#  DONE Sound: Better noise by changing wavX every frame (at least in channel 1)
#  DONE Sound demo: Play SMB Underworld tune
#  DONE SPI: Also reset state at soft reset
#  DONE Fix clobbering of 0x81 by SPI SYS functions #103
#  DONE Control variable to black out the area at the top of the screen
#  DONE Fix possible video timing error in Loader #100
#  DONE Fix zero page usage in Bricks and Tetronis #41
#  DONE Add CALLI instruction to vCPU
#  DONE Main: add Apple1 to main menu
#  DONE Replace egg with something new
#  DONE Split interface.json and interface-dev.json
#  DONE MSBASIC
#  DONE Speed up SetMemory by 300% using bursts #126
#  DONE Discoverable ROM contents #46
#  DONE Vertical blank interrupt #125
#  DONE TinyBASIC: Support hexadecimal numbers $....
#  XXX  Expander: Auto-detect banking, 64K and 128K -> needs FIX
#  DONE Cardboot: Boot from *.GT1 file if SDC/MMC detected
#  XXX  CardBoot: Strip non-essentials
#  XXX  CardBoot: Fix card type detection
#  XXX  CardBoot: Read full sector
#  DONE Apple-1: Memory mapped PIA emulation using interrupt (D010-D013)
#  DONE Apple-1: Include A1 Integer BASIC
#  DONE Apple-1: Suppress lower case
#  DONE Apple-1: Include Mastermind and 15-Puzzle
#  DONE Apple-1: Include mini-assembler
#  DONE Apple-1: Intercept cassette interface = menu
#  XXX  Reduce the Pictures application ROM footprint #120
#  XXX  Mandelbrot: add more color schemes, eg. with permutations of RGB
#  XXX  Main: Better startup chime, eg. sequence the 4 notes and then decay
#  XXX  Main: Some startup logo as intro, eg. gigatron letters from the box
#  XXX  Racer: Control speed with up/down (better for TypeC controllers)
#  XXX  Racer: Make noise when crashing
#  XXX  Loader: make noise while loading (only channel 1 is safe to use)
#  XXX  Faster SYS_Exec_88, with start address (GT1)?
#  XXX  Let SYS_Exec_88 clear channelMask when loading into live channels
#  XXX  Investigate: Babelfish sometimes freezes during power-on?
ROMv6 stable:

Code: Select all

#  Ideas for ROM v6+
#  XXX  ROM functions: SYS_PrintString, control codes, SYS_DrawChar, SYS_Newline
#  XXX  v8080 prepping for CP/M
#  XXX  vForth virtual CPU
#  XXX  Video: Increase vertical resolution with same videoTable (160 lines?)
#  XXX  Video mode for 12.5 MHz systems
#  XXX  Pucrunch (well documented) or eximozer 3.0.2 (better compression)
#  XXX  SPI: Think about SPI modes (polarities)
#  XXX  I2C: Turn SPI port 2-3 into a I2C port as suggesred by jwolfram
#  XXX  Reset.c and Main.c (that is: port these from GCL to C, but requires LCC fixed)
#  XXX  Need keymaps in ROM? (perhaps undocumented if not tested)
#  XXX  FrogStroll (not in Contrib/)
#  XXX  How it works memo: brief description of every software function
#  XXX  Adjustable return for LUP trampolines (in case SYS functions need it)
#  XXX  Loader: make noise when data comes in
#  XXX  vCPU: Multiplication (mulShift8?)
#  XXX  vCPU: Interrupts / Task switching (e.g for clock, LED sequencer)
#  XXX  Scroll out the top line of text, or generic vertical scroll SYS call
#  XXX  SYS function for plotting a full character in one go
#  XXX  Multitasking/threading/sleeping (start with date/time clock in GCL)
From my point of view, anything that doesn't meet these requirements as a minimum, doesn't deserve the official ROM labels.

This is why I named my ROM ROMvX0, it's too much of a departure from what Marcel and Walter originally envisioned and even though it's 99.9% compatible with previous SW, that plus the missing features from the lists above means it has strayed too far from the original vision.
lb3361
Posts: 249
Joined: 17 Feb 2021, 23:07

Re: ROMv5 ?

Post by lb3361 »

The purpose of this thread was to discuss what to do now that we essentially have what Marcel had planned for v5. This was intended to be purely technical but that was maybe premature. In relation to at67's post, there are in fact two questions to answer:
  1. Should there be a v5 release now that Marcel's list is reasonably complete?
  2. What to do after that?
The second question is problematic. Because the wish list Marcel left for v6 resembles a summary of the forum discussions in 2019, I tend to believe that Marcel's plan was not set in stone. On the other hand, the only way to go forward is to achieve some kind of consensus.

Returning to the first question ---which was the purpose of this thread,--- I personally care very much about Walter's point of view because Walter and Marcel were friends in real life. When I read Marcel code, I can see his brilliance, but this is a very small part of the man he was. So, when Walter above says that calling it ROMv6 is an option, I read that he would find acceptable to leave ROMv5a as Marcel's unfinished opus, and that further developments should continue as v6 instead of pretending to finish v5. This is not what I had in mind, but, if this is indeed what Walter means, this strikes me as a very decent thing to do. But that would also mean releasing a v6, which partially orients the answer to the second question.

So what should we do regarding question 1?
walter
Site Admin
Posts: 149
Joined: 13 May 2018, 08:00

Re: ROMv5 ?

Post by walter »

Indeed I would see it as a nice way of having Marcel's work finalised in ROMv5a, which means that the new rom would be ROMv6.
But I can also live with it being called ROMv5. If Marcel had not passed away, it would have become ROMv5.
Post Reply