The floating point encoding in the NEC is much different than the other
models. The M100/102/200, etc. use BCD encoding, but I never could
figure out how NEC was encoding it.
Some bizzare encoding where single precison ZERO is represented as 00h
00h C7h 00h
Ken
On 2/19/23 12:33 PM, Stephen Adolph wrote:
Yah I'm not sure it is actually doable, in a reasonable amount of time
effort.
It is hard to separate data tables from code.
I found one disassembler that was capable of labeling, and tracing
code, but it did not support undoc opcodes, so it wasn't a good
disassembly to use.
I think all the issues could be overcome, but it would be a sizable
amount of effort indeed.
I did learn some python in the process.
On Sun, Feb 19, 2023 at 2:48 PM Gary Weber <g...@web8201.com> wrote:
Hey Steve....
So this is definitely going to be pretty involved. As people have
already stated, the math subsystem of the Model 100's vs. NEC
8201's version of BASIC is pretty different. Going through that
list of addresses and just looking at the instructions being done
by the M100 for each as yielded no results when trying to match
them up with NEC equivalents when looking at both of my master
disassemblies for each ROM.
I have documentation on a lot of the NEC's math functions, so if
there's a way to figure out *what* each of those M100 calls are
trying to do from SuperROM (and I'm guessing from the Lucid app),
then we may be able to find equivalents in *functionality*, and
then be able to add a bit of of code in order to get the calling
convention and result output translated back into what SuperROM
wants. It would be a pretty daunting task, IMO.
Pretty much everything else in the machines are pretty similar,
except when it comes to BASIC. I've even seen cases where math
calculations give results that are in a slightly different
precision between the Tandy & NEC flavors. (This was something to
do with the ATN() function if I recall correctly.)
Gary
On Sat, Feb 18, 2023 at 5:39 PM Gary Weber <g...@web8201.com> wrote:
Hi Steve,
Well first of all, it's awesome you've got a renewed interest
in this little project!
One resource you might also find helpful is the ModelT Memory
Map Database:
https://www.web8201.net/default.asp?content=modelt_memorymaps/mapview.asp
I'm also willing to assist with the conversions on those
addresses. I'll take a first stab and finding the equivalents
for the NEC on your list.
Gary
On Sat, Feb 18, 2023 at 1:49 PM Kenneth Pettit
<petti...@gmail.com> wrote:
Hey Steve,
Looks like the NEC and M100 math routines are a fair
amount different.
I have started a task of annotating the NEC VirtualT
disassembly listing with the hand-coded changes I made to
the M100 disassembly. We'll see how far I get along this
path (There are a LOT of additions I made by hand).
Ken
On 2/18/23 12:07 PM, Stephen Adolph wrote:
Reviving this thread.
SuperROM uses RST1 to make "trampoline" calls to the main
ROM.
I've gone through all of the RST1 calls that SuperROM
makes to the M100 main rom.
Most convert well.
The really big gap is that the math routines are very
different in PC-8201.
If there is anyone motivated to help, It would be helpful
to figure out the equivalent calls PC-8201 calls for this
list of M100 main ROM calls.
0x30C2
0x31B5
0x31B8
0x31BB
0x31C1
0x31C4
0x31CA
0x31CD
0x3469
0x3472
0x34D2
0x3501
0x3510
0x3513
0x35BA
0x35CF
Ideally requiring no major code rework on SuperROM to
make it all work.
On Mon, Jul 12, 2021 at 8:30 AM Stephen Adolph
<twospru...@gmail.com> wrote:
Noting that SuperROM has never been found (or never
released?) for NEC, it seems to me given what I know
about making applications run on both platforms, that
it should be very straightforward to translate the
M100 SuperROM into an NEC variant. After all, the NEC
and M100 are so similar.
Does anyone have any thoughts on this?
Process could be:
- Disassemble
- find the trampoline, and adjust for NEC memory map
- look for "trampoline" calls to the main ROM, and
convert to NEC addresses
- look for upper RAM addresses, and convert to NEC
addresses
---> this could be a bit tricky I admit, because it
may not always be apparent that a register pair value
is being used as an upper RAM pointer
- adjust the hardware interrupt if needed
cheers
Steve
