• Please review our updated Terms and Rules here

Epson HX-20 - FORTH ROM

The attached ZIP archive has been updated with my latest status of the Forth ROM disassembly.

The files should now be very, very close to being assembled, e.g. by the A09 assembler.
It may be easier to recreate the ROM for different system ROM versions this way, as one only has to change the list of entry points.
I believe that there are at least 250 unused bytes at the end of the ROM as well as some interspersed unused bytes which would allow adding one or two extra words. e.g. for talking to one of the the serial interfaces.

As this flow was rather exhausting, I will pause here and continue in a few days or weeks.

Martin
 

Attachments

  • f_rom.zip
    111.5 KB · Views: 9
Martin Hepperle said:
The attached ZIP archive has been updated with my latest status of the Forth ROM disassembly.

The files should now be very, very close to being assembled, e.g. by the A09 assembler.
It may be easier to recreate the ROM for different system ROM versions this way, as one only has to change the list of entry points.
I believe that there are at least 250 unused bytes at the end of the ROM as well as some interspersed unused bytes which would allow adding one or two extra words. e.g. for talking to one of the the serial interfaces.

As this flow was rather exhausting, I will pause here and continue in a few days or weeks.

Martin
Click to expand...
Nice work, Martin! One step closer to producing a 1.1 version.
 
>>> One step closer to producing a 1.1 version.

I thought I had already produced a set of patches for your FORTH ROM for V1.1 back in post #80 (except for the MON word currently). Before doing any more work, I would like to know whether these work or not.

Having the source code (so we can assemble it for any variant of the system ROMs) would be the ultimate - but we still need to identify a correct set of patches for each ROM variant so we can embed them in the source.

Dave
 
Dave,

I spent some more hours to get a more complete understanding of the links between these ROMs and also looked into the EUROPE V1.0 ROMs and the required patches.

As I finally learned, at least one of my HX-20s (which shows BASIC V1.0) has a mix of what I call JAPAN V1.0 and EUROPE V1.0 Basic ROMs. Thus your set of patches did not work for this device and I fell into a Trap!

After I used the 1.0 patches only for the upper Basic ROM (EUROPE 1.0) and the original bits as for the JAPAN 1.0 for the lower Basic ROM references it finally worked.
Even the MON word works, because the EUROPE V1.0 Basic ROM luckily has the same structure (in this area) as the JAPAN 1.0.

In a next step I will look into the ROMs of my other German HX-20s to see which combination, they have. Some show Basic V 1.0 and others V 1.1.

I did not yet try any patches on my 1.1 versions yet, as I have to remove the internal RAM extension, with its overlapping addresses.

As I tend to forget these details after a year or two, I wrote a short document where I used 3 parallel columns for the JAPAN 1.0, EUROPE 1.0 and EUROPE 1.1 versions. I hope that no fourth column has to be added...

The attached document shows the destination in context, which makes it easier (at least for me) to crosscheck before patching a ROM for an unknown HX-20. This was written for myself, but may also be helpful for others.

I called my patched EPROM 1.0-1.1 to reflect the combo.

Martin
 

Attachments

  • Forth ROM Patch Notes.pdf
    149.9 KB · Views: 9
You guys are doing great work, I'll let you figure that out... unlike me, you already have the tool chain in place, and the more cooks the worse... @Martin Hepperle did you see my post https://forum.vcfed.org/index.php?threads/epson-hx-20-forth-rom.1238041/page-6#post-1250522 ?

I would also suggest to publish the checksums somewhere, because it seems there are also patched versions around. This is getting very confusing otherwise... in fact, I can only partially follow through the differences by now. I must say that I am also "happy enough" with my working 1.0 FORTH thanks to Geoff's 1.0 images, and as I said, for me that is good enough. I'd be happy to help to burn 1.0 EPROMs for folks that don't have their own programmer. Having said that, even though my interest in getting 1.1 FORTH working is only marginal, I still think it is great that you guys are trying to sort it out.

In a nutshell, what's the difference between 1.1 and 1.0 anyhow, does anybody know (bugfixes, functionality, ..) ? Is it worth the effort?
 
Last edited:
Remember, I've had my HX since they first came out, and I was using it a LOT for the first few years, esp with the TF-20..
I was not troubled by any problem with the 1.0 ROMs. I vaguely remember a mention of something within the BASIC, but it wasn't bothering me.

I don't know when the 1.1 versions came out, but I don't remember any mention of that at the time, and no suggestion that it was worth the trouble to upgrade. I now understand that if I had done so, I'd have had a MAJOR problem with the FORTH.

I'd suspect that the changes were minor, and mainly cosmetic? I was worried that the changes might have been needed to take account of some hardware differences in later manufacture, but this may not be so. The 1.0 system seems to be OK with the later models, although we don't know what the 1.1 set does with the earlier model (like mine). I don't plan on testing that, even if I was able to!

Geoff
 
>>> As I finally learned, at least one of my HX-20s (which shows BASIC V1.0) has a mix of what I call JAPAN V1.0 and EUROPE V1.0 Basic ROMs. Thus your set of patches did not work for this device and I fell into a Trap!

Yes Martin, I did read and understand your original statement regarding the different V1.0 ROMs.

This is always a problem when developers use a ‘backdoor’ method of accessing functionality. I have seen exactly the same thing numerous times in the Commodore PET.

>>> Is it worth the effort?

Almost certainly not! But that is not the reason we have this hobby is it...

If I can get confirmation that the patches I identified do actually work (I haven’t got one of these machines to test them on) I can then ‘shell out’ the patches for as many different sets of system ROMs as necessary.

Whether anyone wants to use them after that is another matter of course! It will, however, avoid the same pitfall for people following in our footsteps in the future...

Dave
 
daver2 said:
>>> Is it worth the effort?

Almost certainly not! But that is not the reason we have this hobby is it...

If I can get confirmation that the patches I identified do actually work (I haven’t got one of these machines to test them on) I can then ‘shell out’ the patches for as many different sets of system ROMs as necessary.

Whether anyone wants to use them after that is another matter of course! It will, however, avoid the same pitfall for people following in our footsteps in the future...

Dave
Click to expand...
@daver2 and @TangentDelta and @Martin Hepperle I really appreciate your work, I was astonished to see that you guys were so willing to step up and embark on this journey. This is a great forum, and a very engaged community, I'd like to contribute something as well, but you guys are better equipped to sort this out for now. And I'd like to learn how I can apply the patches myself later this week (and learn how to use the assembler and such - I am well-versed with assembly, just not with that obscure CPU and tool chain, so it's a bit of a learning curve). Unfortunately, I won't be able to do this next or coming week as I have something going on, but sooner or later I'll get to it. I guess that by then somebody else will have done it. Totally agree with the "it's a hobby" fun project remark of course!
 
To apply the patches load the existing FORTH ROM code into an EPROM programmer.

This would load the ROM code itself within the EPROM programmer such that address $6000 becomes address $0000.

Apply my patches remembering that:

Addresses $6xxx become $0xxx.
Addresses $7xxx become $1xxx.

Patching a WORD value involves patching the address specified with the HIGH byte of the value followed by the LOW byte of the value in the next address.

Burn a new EPROM and test at the conclusion of applying the patches. Make sure you have a blank EPROM of course before starting this process!

It may be possible to apply the patches automatically to a binary image of the ROM within a file. I used to have a program to do this, but I would have to go and hunt for it.

Your EPROM programmer software may have a feature to do this itself.

Dave
 
daver2 said:
To apply the patches load the existing FORTH ROM code into an EPROM programmer.

This would load the ROM code itself within the EPROM programmer such that address $6000 becomes address $0000.

Apply my patches remembering that:

Addresses $6xxx become $0xxx.
Addresses $7xxx become $1xxx.

Patching a WORD value involves patching the address specified with the HIGH byte of the value followed by the LOW byte of the value in the next address.

Burn a new EPROM and test at the conclusion of applying the patches. Make sure you have a blank EPROM of course before starting this process!

It may be possible to apply the patches automatically to a binary image of the ROM within a file. I used to have a program to do this, but I would have to go and hunt for it.

Your EPROM programmer software may have a feature to do this itself.

Dave
Click to expand...
Thanks, @daver2 Yes on this bare-metal level this is of course doable (and I could have done that), but it might maybe more sense to wait until we can actually re-assemble a patched version from the source, or?
 
In order to actually do something useful with this Forth, I complied a list of words and a short summary.
When complete, this will be cast into a Quick-Reference Guide.

However, there are a few words, especially dealing with the screen editor and some HX-20 specific functions, which need further exploration.

I understood that someone has a copy of the original documentation?

Could you look up the words which I have marked with ???? in the table below and provide their input and output parameters and a brief description of what they do?

Otherwise they have to be reconstructed by looking at their source code.

Thank you,
Martin
 

Attachments

  • Forth-QRG.txt
    19.6 KB · Views: 11
Hello Martin,

Yes, I have the original manual. It's not very good for scanning, esp with the 'scanner' I have, i.e. a fairly basic EPSON printer/scanner. Some pages would come out OK, others not so. The manual is printed using a dot matrix printer, and the priginal pages have then been reduced from A4 to A5. Your document here is already far more use, and readable!!

I've had a quick look at your doc, and the manual. A number of the words you ??? are EDITOR words, and these are detailed in the Editor section and are NOT in the alphabetic listing. For example, B is used within the editor, and moves the cursor back by the number of characters in PAD.

You refer nearby to ANOTHER. I see no mention of this. I trust that you are aware that FORTH being what it is there could well be a number of words in the dictionary that were never intended to be used directly, they are in effect 'internal' sub-routines. It is VERY possible that a number of other words/definitions in your list may also be 'hidden'.

Also, a named item that would appear via VLIST could in fact be a Constant or a Variable, and not 'code' at all. This is where the use of the DISPLAY definition might help, and when I get it sorted out the UNCOMPILE definition would explicitly state that a specific word was either a Constant or a Variable. Using DISPLAY, the PFA for a Constant would show as 6628 and a Variable would show 6640.

I admit that I was thinking that it would be better to do what you have done, rather than to scan the manual (most of which is generic FORTH anyway). So GREAT that you've started this.

I will go through your listing, and add what info that I can. I should also mark those words that seem to be 'hidden' - another example of this is a set of words starting # which are not mentioned in the manual.

Geoff
 
Last edited:
Usually, there are only three or five connection from Forth to the OS.There there is a KEY, KEY? ( or ?KEY ) and an PRINT. For mass storage, it can be a little more complicated. There is usually something to move the file pointer, a write string or byte and a read string or byte.
These are usually vectored through the USER table, so they can be re-vectored to another entry point. The User variables would be loaded into a block of RAM on boot so that they would be available when the main interpreter starts. There are often other values in the USER table for other things like backspace and such that may need changing on the fly.
This would be true for most all Forth's based on FIG Forths.
Most Forths try to minimize specific links to the ROMs that can't be easily re-vectored.
Dwight
 
As I was already digging, I found a manual for the BBC Computer Forth on archive.,org. This Forth was also created by HCCS and there I found the description of the editor words. Most words seem to be present in the HX-20 Forth, but one has to try them out individually.

I have updated the list according to these words. So only a few HX-20 specific ones remain, which maybe
Geoff could add without the need to scan the whole documentation.
 

Attachments

  • Forth-QRG.txt
    19.8 KB · Views: 8
Aha!!!

Yes - I've found this item now, and it's a MUCH better production. Most of the content is VERY similar. The two documents are almost the same number of pages.

Can't really blame HCCS - I'd guess that the anticipated sales for the HX version would have been tens, while those for the BBC prob hundreds. A print job like the BBC doc would NOT have been viable for the HX version. Then again, they could have used the BBC book with a HX-20 addendum?

Geoff
 
OK, I'm working on the document. Made a few changes already, and lots of adjustments re line length so that I can print it out - all my laser printers discard everything after the width is exceeded! Sorted quite a few of the special HX words, added some clarifications here and there.
Quite a lot more still to do. Still some words not in my docs, I'll see what I can work out from the code.

Still trying to get UNCOMPILE working. It uses two screens, and the second normally should load automatically (using ---> at the end of the first) but this seems NOT to work properly with the .WAV process. Still working on this.

Geoff
 
Geoff,
maybe do not yet spend too much time on formatting, as I think we can cast this raw text into a printable version later.

I have imported it into Word and worked on the many typos from my side.
Improved raw text and a first layout sketch attached.

The HX-20 specific words are still marked ????

Martin
 

Attachments

  • HCSS Forth Words.txt
    20 KB · Views: 7
  • HX-20 Forth Words.pdf
    155.6 KB · Views: 13
I've finally got the UNCOMPILE definition to work, so the items are attached.

The two disp files are the text of the screens as loaded, for information.

The two .WAV files are the saved data, LOAD as before, note you need the CASS first to swap from MCASS default.

19 LOAD first, start the WAV playing when the screen says 19 Searching.

Then, as soon as the screen changes to say:

20 Searching

then the system has done 19 and it's looking for the second file, so start the forth020.wav playing.

Once it's all loaded, there will be a little garbage on the screen, the process is displaying the text in the footer (a repeat of the header) in the SAVEM data. Although this messes the screen, it does not effect the LOAD process.

Operation is better with the printer active. UNCOMPILE VLIST - for example - will produce something close to the original definition. There are differences, for example various words will appear regarding the looping/branching that were not in the original, which used things like IF and THEN. Other items may appear as literal numbers.

Have a play.

I'll scan the magazine article and send that, this will help.

Oh, if you follow the suggestion earlier and record the two WAV files to a tape, and then just play the tape, this should handle the transition from 019 to 020 automatically. The system could handle multiple screens loaded in succession, and from tape this would be a lot easier.

Geoff
 

Attachments

  • UNCOMP.ZIP
    70.3 KB · Views: 8
You must log in or register to reply here.
Back
Top