Add the possibility to create ROMs

[AugustoRuiz]

It would be nice to be able to specify at project creation that the output of the build is a ROM.

The ROM should be linked at 0xC000, and must have a header with the following data:

.db 1 ;; BACKGROUND ROM
;;ROM VERSION
.db 0,0,1 ;; MARK, VERSION, MODIF (0.0.1)
;;RSX Command definition address
.dw RSXCommandTable ;; No problem if this is relocatable
;; RSX Command jump table
jp initRom
jp rsxCmd1
jp rsxCmd2
;; ...
RSXCommandTable: ;; Could be here or anywhere else
;; List of names for each function in previous table. End of name is marked with bit 7 set.
.db '@' + #0x80 ;; First name (init rom) set to a non BASIC callable name.
.db 'RSXCmdName', '1' + #0x80 ;; Second name = |RSXCmdName1 (will call rsxCmd1) 
.db 'RSXOtherNam', 'e' + #0x80 ;; Third name = |RSXOtherName (will call rsxCmd2)
;; And so on...

;; IN:
;;   DE= Lowest RAM address available
;;   HL = Highest RAM address available
;; OUT
;;   DE = New lowest RAM address available
;;   HL = New highest RAM address available
;;   Carry flag on to indicate it went Ok
initRom:
   ;; Do whatever you need to do to init here
   scf ;; Notify it went OK
ret

rsxCmd1:
ret

rsxCmd2:
ret

See:

CPCWiki forum thread

[cpcitor]

Good idea! That 16k ROM competition in 2013 was a great idea! I regret my work did not let me enough time to make a prod at the time. But I started cpc-dev-tool-chain so it gave a good impulse.

IIRC this is a natural job for a crt0.s file.

There is a downside here: many routines in cpctelera are optimized assuming code runs in RAM and can self-modify. Just deploying such code to a ROM obviously won't work, and need:

• either special handling to re-deploy code to RAM,
• or giving up a number of optimized-beyond-death routines which are the main strength of cpctelera.

The special handling can be of two kinds:

• Separating the ROM-incompatible code into a kind-of library, while keeping main code in ROM is possible but not obvious. It can be done with special makefiles, etc.
• Perhaps the simplest would be to link all code to a RAM address, make a compressed image of it that goes in ROM as data, and a decompressor that uncompressed code at start time to RAM address.

So, not obvious because different projects may need different cases.

In all cases you have to take care of address range where ROM appears. If you never read video RAM then code in ROM at C000 is fine, etc.

Incidentally, I've been thinking to do a ROM-targetting crt0.s in cpc-dev-tool-chain for a while. There, no assumption of code in RAM, things would run pretty smoothly by default.

[lronaldo]

@cpcitor Yes, @AugustoRuiz and I agree with your analysis. We have been discussing it for a while. Just some things to take into account:

• Although CPCtelera provides a low-level library, it is always thought to be used with or without it. In fact, several projects use CPCtelera just for tool convenience but without using the low-level library.
• Low-level library functions have comments in documentation about their use of self-modifying code. Users can now before hand which functions can be used for execution from ROM.
• Some functions have ROM-enabled versions (marked with _r). There are still plenty of functions that would need reworking for ROM, but that would be nice for those willing to create ROMs and use CPCtelera functions.

As a first step, giving users the possibility to create ROMs seems not difficult. As you say, something like a crt0.s with ROM header code would be enough for enabling this ability. After that, many other improvements can be worked out as per request basis.

[AugustoRuiz]

Working example for lower-ROM (the simplest one, except for the hardware initialization required). sf2rom.zip