Re: Redesigning a new PROM for //e and //c hardware

[Benoit0123 <bgilon@free.fr>]

mspangler wrote:
> 
> The debug ROM is available out there somewhere. I found a copy, but I'm
> not
> sure where at this point. 
> 
> I was undertaking a project to make the IIe rom do proper disassembly of 
> 65C02 code. I mostly succeeded, but finding the room was quite an
> exercise.
> I had to replace the slot-3 check, and do some fancy vectoring. In the
> enhanced IIe ROM the disassembler is scattered all over. 
> 
> That was the second half of the project. The first half was to put several
> of the Beagle Basic routines in ROM to replace the cassette port routines.
> I have the Else, Tone, Swap, and a Repeat Until (which was not Beagle
> Basic), and I converted USR() to readkey to save having to peek whatever
> that was. There was also enough room to have Timer (or Wait) but then I
> had
> to sacrifice Flash to get a spare token. 
> 
> The changes to the token lookup table broke Program Writer,  but GPLE
> still
> seemed to work.
>
Thank you for your message.. I consider it as a proof that such enterprise
is worth it.
Just to sum up my thoughts on the project.
I plan to:
a) develop a new OSS project (for DOS3.3) with the claimed goal of building
new ROMs for a given configuration (computer/CPU).
b) develop a program that will copy the ROM dedicated to Applesoft ($D000 to
$F7FF) to LC RAM, disables the INT DOS 3.3 command, add a new command "FPX"
to DOS 3.3 for enabling 16bits version of Applesoft, patches the LC RAM with
enhanced code at multiple places.
c) begin testing with typical BASIC programs for non regression and
performance improvements;
d) publish result ROM files for computers I have at home and for the two
flavors of CPU not considered in Applesoft (65C02 and 65802/16).
e) develop a software working by interruption and that monitors the time
spent in each part of the BASIC code memory space;
f) find someone who has the proper equipement to produce suitable [E]EPROM
chips for integration into a //e, //c.

Just to give you an idea on the performance you could achieve on your BASIC
programs:
Here is an extract of some ROM routine, trying to find a variable in memory
which matches a name given upon entry.
HE053 LDA $69
 LDX $6A
 LDY #0
}LOOP STX $9C
]LOOP1 STA $9B
 CPX $6C
 BNE :0
 CMP $6B
 BEQ HE087
:0 LDA $81 ;VARNAM setup upon entry with b7 encoded
 CMP ($9B),Y
 BNE :1
 LDA $82
 INY
 CMP ($9B),Y
 BEQ :3 ;Found a matching variable in memory
 DEY
:1 CLC
 LDA $9B
 ADC #7
 BCC ]LOOP1
 INX
 BNE ]LOOP
...

* If a variable in memory does not match the provided name, then create one
except if called from a certain address 
HE087 PLA
...

* Variable found
HE0DE LDA $9B
 CLC
 ADC #2
 LDY $9C
 BCC :0
 INY
:0 STA $83
 STY $84
 RTS

And now the proposed transformation (65816 CPU version, untested but
suffiicient for you to get the idea)
 CLC
 XCE	Native mode
 REP $20	Mem/Acc is  16bits, Index regs are 8bits
 MX %10	Merlin trick for coding immediate adressing mode instructions
 LDA $69
]LOOP STA $9B
 CMP $6B	16bit arithmetic
 BEQ HE087
 LDA $81	16bit arithmetic
 CMP ($9B)
 BEQ HE0DE
 LDA $9B	16bit arithmetic
 CLC
 ADC #$0007
 BRA ]LOOP
...

* If a variable in memory does not match the provided name, then create one
except if called from a certain address 
HE087 LDA 1,S
...
 SEC
 XCE	Back to emulation mode
 MX %00 Advise Merlin (may be removed)
 RTS

* Variable found
HE0DE LDA $9B	16bit arithmetic
 CLC
 ADC #$0002
 STA $83
 SEC	Back to emulation mode
 XCE
 MX %00	Advise Merlin (may be removed)
 LDY $84
 RTS

If you manage statistics upon time spent within this code extract. the
internal loop is run M * (N -  1) / 2 times. M being the number of variables
lookups run in name of your program (really a big number if you take into
account FOR/NEXT loops within your program) and N being the total number of
variables declared within your program.
I do not have Merlin to compute the # of cycles it would take but I bet the
performance gain easily outperforms a unmodified code running at 2.8 MHz
instead of 1MHz.

Similar strategic places are candidates for such optimisations (eg. FNDLIN
for returning the address of a BASIC line, given its number).

Even when considering a 65C02 CPU, two bytes and associate cycles could be
removed from the original routine designed for plain vanilla 6502...
However, not enough to replace it with a major feature....

Regards,
Benoît