• Please review our updated Terms and Rules here

Epson HX-20 - FORTH ROM

Great. So, these are (most) of the changes needed to the FORTH ROM to allow it to work properly with the 1.1 System.

May I suggest that if these are done, then the Startup message that presently shows Forth V1.0 be changed to show V1.1 as well?

Geoff
 
>>> Great. So, these are (most) of the changes needed to the FORTH ROM to allow it to work properly with the 1.1 System.

Until we find something further...

>>> May I suggest that if these are done, then the Startup message that presently shows Forth V1.0 be changed to show V1.1 as well?

Of course, a good idea.

Patch the byte at address $7040 from $30 to $31.

We could also patch the date from 1982 to 2022...

Patch the four bytes at address $7058 from "$31 $39 $38 $32" to "$32 $30 $32 $32".

Dave
 
Hi guys, you are doing great work!

Some time ago I also looked into the Forth ROM, more with the intent to study the words included than to patch anything.

But I also created a primitive disassembly and I am attaching some files here.
Maybe the tables with NFA/LFA addresses are useful. I used them to partially automate the generation of labels for disassembly of the Forth ROM.

The disassembler I used was DASMX - maybe not the best, but o.k.
Command line : dasmx -o 0x6000 f_rom.bin
Uses the .sym file for labels etc.

The jump addresses into BASIC which i found are the same one that you found - so the patches you proposed may be enough to make it work under 1.1.

I did not start to distinguish between raw and cooked code words (i.e. whether a WORD is written in Forth or assembly).
This could also be automated by examining the header fields of each word, but is maybe not worth the effort.


Martin
 

Attachments

  • f_rom.zip
    84.4 KB · Views: 9
Last edited:
Martin,

I will have a look at your disassembly later when I have a bit of time (and access to a machine that can open a ZIP file!).

Good news regarding your confirmation of the BASIC calls though...

Always good to have multiple eyes looking at a problem :)!

Dave
 
I have had a quick look at your disassembly.

One thing that did confuse me is that you have used a 6809 disassembler.

There does seem to be a bit of confusion as to what CPU is actually within the Epson HX-20. It is a Hitachi 6301 - which (IMHO) is an upwardly compatible version of the 6800 (not the 6809). The 'upgrade' has been to add the 'joining' of the two 8-bit accumulators A and B together as a 16-bit 'D' register. These instructions are on the 6809. However, (in my mind) the 6809 instruction set is different. For example, the opcode 0x01 (in the 6800) is a NOP and the opcode 0xCE (in the 6800) is LDX immediate. The equivalent (in the 6809) for the opcode 0xCE is LDU and not LDX.

I have a couple more calls (MON to $D310 and FEED to $E2A5) that appear to be 'hidden' by treating the two pointers that follow the individual FORTH words as instructions.

Yes, looking a bit closer at the disassembly for BEEP indicates that the 6809 disassembly is making a mess of the code!

7B E1 7B FA are two (2) pointers (the first to the next/previous FORTH word in the vocabulary and the second to the code for this word).

Opcodes 33 33 are actually two (2) PULB instructions (only the least significant byte of the word value on the stack is used).

Opcodes 32 32 are actually two (2) PULA instructions (only the least significant byte of the word value on the stack is used).

You then end up at the (correct) JSR $E3F2.

However, there is a pretty good alignment of the external JSR targets and internal words nonetheless!

Many thanks for sharing.

Let's see how well my patches work!

I will still need to look into the MON call of $D310 yet though. I will do a little disassembly of the BASIC V1.0 code.

Incidentally, I was using the instruction set of the 6800 for my disassembly - and (when I came across an 'illegal' instruction) flipped over to the 6301. Mainly because I have a concise 6800 instruction list to hand that I use quite often...

Dave
 
Last edited:
Dave,

you may be right - I did not think too much about opcode differences towards the 6809 and at least the JSR opcode must be identical so I was satisfied for a quick look.
In the past I was only assembling and not disassembling HX-20 code. And for assembling I used a 6301 assembler.

I had not found a 6301 disassembler - which tool did you use?

And: at least the address tables, e.g. in the Excel workbook could be useful if you have not already placed labels at the Forth words.

Martin
 
>>> I had not found a 6301 disassembler - which tool did you use?

Me :) (i.e. by hand).

I haven't looked at the EXCEL workbook yet.

By the way, where are you based?

Dave
 
Dave,

Martin is in Germany, and has produced some brilliant stuff for the HX, incl a PDF covering a wide range of useful info about the device.

Actually, there IS a disassembler for the 6301. Something called DASMX. I'll attach a .ZIP of the system. This is a multi-processor system, so it's a fairly complex package. I had a play with, did enough to confirm that it DOES work, but it was too much trouble for my immediate needs so I didn't go much further. But it could well be worth YOUR trouble for what you're trying to do.

There is also the disassembler that Julian Wald produced, I've got that, and that certainly works, BUT on the HX only (DASMX is a PC system) and it outputs to the HX printer. This may not be any use to you, esp as a substantial part of the code is HX ASM. Aside, it may actually be the work of Elizabeth Wald, I think the original article was under her byline.

Keep up the great work.

Geoff
 

Attachments

  • dasmx140.zip
    395 KB · Views: 8
Extra note - Martin referred to DASMX, the version I attach above says it DOES support 630x processors (Hitachi) so I don;t know why it might seem to be producing 6809 code, maybe there are different versions? It supports 680x as well of course. I think it needed telling which CPU was the target, so the command line that Martin used may not be correct.

Geoff
 
Indeed I used this disassembler - but have my config at home.
I have to check why I told it to use 6809 - I will change that to 6301 if it is supported - thank you for the hint, Geoff!

Einen schönen Abend!
Have a nice evening!
 
I have found various websites that state that the processor used is a 6809 derivative, but this is clearly not the case - it is a 6800 derivative.

The default processor for dasmx is stated to be the 6800, so either a 6809 has been specified or the default processor has changed at some point (depending upon your configuration file).

I had another quick look at the disassembly and some of the FORTH pointers after the word name have caused some JSRs to be ‘eaten up’. This issue was also compounded by the different opcode to mnemonic mapping used by the 6809. Some of the JSRs were eaten up as operandi. All good fun!

I know Erlangen and Karlsruhe quite well (Siemens).

Dave
 
O.K. - I have updated my files using the disassembler in 6301 mode.
The disassembly now contains some of the Forth words with their threaded address lists.

I also tested the original Forth ROM in a European HX-20 with BASIC 1.0. It does not work and I believe the situation is the following:

There should be two general variants of ROMs:
- Japanese version = includes DIP switch settings for US/UK
- European version = here, the DIP switch settings for US, UK, Italy and Spain have been replaced by Norway and Sweden and ASCII versions of France, Germany and Sweden.
(Technical Manual page 3-34)

In order to integrate the different languages with accented characters, the internal code was moved around a bit.
This is due to different character tables and e.g. sort order of accented characters.

But the official jump tables (which should be used by software developers) were maintained.
As Forth uses some of the undocumented internal functions of BASIC ROMs, it does not work with other ROMS than the set it was designed for.
This was no clever decision, even if it might have spared a few bytes or increased the speed of the code slightly.

Therefore one would have to patch at least two versions of Forth:
- original, unpatched one
- one for Europe Version 1.0
- one for Europe Version 1.1
- maybe 1.1 Japan, if it exists

(The latter two are in the attached ZIP file)

I have only German HX-20s with the "Europe" ROMs 1.0 and 1.1 BASIC.
This means that versions 1.0 and 1.1 exist for the European ROM version.

The original Forth ROM does not work with the European Epson BASIC 1.0 ROMs, nor with 1.1.

As the Forth ROM was developed in the UK, it is very likely that it was developed with the "Japan" ROMs.
Therefore it works with version 1.0 of these "Japan" ROMs.
I am not sure, whether there is a 1.1 version of the "Japan" ROMs.
Maybe someone with a HX-20 from the US can comment on that?

Your patches are probably for the "Europe" version of BASIC 1.1, I guess.

Martin
 

Attachments

  • HX-20-ROMS-EUROPEAN.ZIP
    55.8 KB · Views: 15
  • f_rom.zip
    87.3 KB · Views: 14
Martin,

That's a nice, concise description of the issue.

I feel much better looking at a 6800 (ish) disassembly...

There is an additional JSR to ROM1 from the FORTH word 'FEED' to $E2A5 that is now in your disassembly.

As you say, it would be good to get a FORTH ROM that works with V1.1 (in whatever 'guise' it is) and then we can look at the other locale versions. It only took me 15 or 20 minutes to identify the patches - so it didn't take much time in the end. Of course, the patches I have produced may be garbage and we still have some problems to iron out!

Dave
 
@Martin Hepperle , yes, the only difference between my Epson US 1.1 ROMs and the European ones that you posted are HX20ROM_E000-FFFF_EUROPEAN_V1.1.bin which corresponds to EPSON ROM E1-HC2.BIN. The other ones are identical; and you are right, the patched FORTH works with my "US" 1.1 ROMs.

I haven't tested the European ones you posted. Your 1.0 European ROMs are different from the ones that Geoff posted, and which are the ones which work with FORTH. So Geoff must have 1.0 US / JAPAN ROMs indeed. They differ in HX20ROM_C000-DFFF_EUROPEAN_V1.0.bin and \HX20ROM_E000-FFFF_EUROPEAN_V1.0.bin
 

Attachments

  • 20220322_203136.jpg
    20220322_203136.jpg
    438.4 KB · Views: 4
Last edited:
And, to add to the confusion - there is YET ANOTHER set of 1.1 ROMs, which is the "French" one, which is different from the European ones (in all 4 images!), and hence from my US Epson 1.1 ones as well:


So, it's very honorable of you guys to embark on the 1.1 Forth porting journey, but you have to pick your battle - I'd suggest to go with the US 1.1 ROMs as the target, like you already started with.

Picture of the French ROM:
 

Attachments

  • 20220322_210242.jpg
    20220322_210242.jpg
    345.2 KB · Views: 4
The so called "French" ROMs are exactly identical to the European V1.1 ROMs which I had attached to my last posting.
I don't believe that there were (for European users) any other ROM sets than 1.0 and 1.1. No "French" "Baravarian" or "Scottish" ROMs.
These ROMs should therefore not be distributed further under the incorrect "French" name.
We should probably always add a note with the CRCs to avoid unnecessary duplication and confusion.

In the US and UK they must have used the "Japan" ROMs, which were designed obviously for this market.

As there seems to be a V1.1 of these Japan ROMs (used e.g. in US and UK), we will have 4 sets in total.

Martin
 
me - not - Iwould like to see a list of the surroundig bytes to make sure they fit my ROMs
Could you create a list with the individual patch adresses and the following 8-32 bytes in the ROM for each patch location?
Ths would be helpful to adapt the ROMs to all 3 versions.
... It can be frustrating to burn-erase-burn EPROMs.
 
I guess that as far as EPSON are concerned, the UK is not 'EUROPE', but is the same as US (and it seems Japan). The designation as 'EUROPEAN' really means NOT-NATIVE-ENGLISH? My device does support a few accented chars as a nod towards European languages, but I assume NOT as much as the EUROPEAN versions.

Geoff
 
@Martin Hepperle seems I need a better diff tool, you are right regarding the "French" ROMs. I computed the md5 hashes and they are indeed identical to the ones in your zip, sorry for the confusion (there must be some other differences in the files that make my diff tool choke)
 
Back
Top