Pr0f wrote:ok - so this is incomplete - and may have inaccuricies in it - the idea would be to build upon it...
Just to clarify Hermes is on 8749 but this code says "CPU: Intel 8049 (MCS-48 family)" so is Hermes on the 8049 as well?
Oh! I guess the 80 is ROM and 87 is EEPROM.
The obvious path for a replacement seems to be the modern 8051 flash units but it might be easier to convert the code to 'C' for an upgrade that could be maintained by anyone.
Yes - 8749 is just an eprom version of the 8049 - and confusingly there is also a piggy back version 8750 (which I have) that has a 28 pin socket built onto a ceramic chip containing the processor - odd beast - but meant to allow more rapid turnaround on development.
I believe there was also a ROMLESS version - the 8039 - which requires an external ROM to work - the Falkengberg keyboard interface had one of these on it I think
That disassembly is from the original IPC, not Hermes. But in any case, well done, that looks quite extensive. Wish I had this a long time ago
At one point I sunk a lot of time into implementing the IPC sound as well as possible in QPC, but eventually gave up when I realized that part of the random number generator relied on an uninitialized register, very hard if not impossible to emulate accurately.
The bits I still have not fathomed out completely:
How sound and serial work together in the state machine - I can see where we turn the speaker on and off - but it's getting to that bit from the rather wonderful and complex state machine - I did wonder if I had the time and patience to map that all out in a big flow chart - but that's a long exercise!!
How the sound parameters are consumed and used to drive the state machine - I concentrated on the serial side - as that was of the most immediate interest to me - since Intel's own notes on implementing serial on the MCS48 suggest only 4800 baud is possible - clearly not as we all know.
What those odd jump tables or data tables are that I still haven't fully back referenced.
As an experiment - I did assemble that code using an MCS48 assembler I found online - it may be the one you found - it's command line only - and it generated a binary file that had the same checksum and passed a fc /b in DOS as a perfect match - but I didn't try blowing that image into a chip to see if it actually worked - that would be the logical next step.
I have to say it's a wonderful bit of code and some really clever table indexing techniques to reduce code size and improve speed here and there - this is an MCS48 driven to it's limits - probably why the superhermes was implemented as a 16 bit pic
mk79 wrote:That disassembly is from the original IPC, not Hermes. But in any case, well done, that looks quite extensive. Wish I had this a long time ago
I am confused isn't it better to work on the disassembly PrOf has posted since that is Hermes and all the other stuff is old crap as well as this being an up date on the status of Hermes?
If an optimiser was used on the Hermes code to squeeze more in to the chip it will be impossible to decipher. Just one level of optimisation of a 'C' compiler on PIC makes it impossible to follow let alone the other four levels that are available. The simple optimisers identify blocks of identical and delete lots of blocks using just one block by indexed jumps and that is enough to lose total understanding. It is quicker to write a new IPC in 'C' than decipher the old one with all the obvious advantages.
mk79 wrote:That disassembly is from the original IPC, not Hermes. But in any case, well done, that looks quite extensive. Wish I had this a long time ago
I am confused isn't it better to work on the disassembly PrOf has posted since that is Hermes and all the other stuff is old crap as well as this being an up date on the status of Hermes?
As opposed to what? I just see people sharing existing work and I really like the extensive nature of the IPC disassembly. I know from personal experience how difficult this is. Hadn't seen the Hermes one yet, but I see this is also a good effort. I still hope the original source code is sometime recovered because the true gold usually is in Laus's comments.
If an optimiser was used on the Hermes code to squeeze more in to the chip it will be impossible to decipher.
The optimizer is called "Lau". This is all assembly code, there is no optimization stage beyond the programmer. Besides, 8049 assembler does not need any further obfuscation, I think it's quite unreadable as-is.
It is quicker to write a new IPC in 'C' than decipher the old one with all the obvious advantages.
You cannot write 8049 code in C. But for a possible "SuperDuperHermes" on a modern chip I would also not advocate writing it in assembler...
