Configuring TI-99 and Geneve emulations in MAME

[+mizapf]

Oh dear, we should have looked there at the first place: https://www.mizapf.de/ti99/mame/changes (I mean, I did not think about that either, so why am I writing this list?)

 

Have a look at the "0.230" entry. I fixed a problem; the AMD/AME decoding was bad for the standard Geneve (the card does not get activated). Please wait until next Wednesday until 0.230 will be released. If you want, I can create an interim build and upload it to Whtech.

 

I've been working on the current state, of course, and you are using the 0.229.

 

(To everyone else: You must upgrade to 0.230 (when it becomes available) if you ever intend to use the IDE card in the Geneve emulation.)

[+9640News]

2 minutes ago, mizapf said:

Oh dear, we should have looked there at the first place: https://www.mizapf.de/ti99/mame/changes (I mean, I did not think about that either, so why am I writing this list?)

 

Have a look at the "0.230" entry. I fixed a problem; the AMD/AME decoding was bad for the standard Geneve (the card does not get activated). Please wait until next Wednesday until 0.230 will be released. If you want, I can create an interim build and upload it to Whtech.

 

I've been working on the current state, of course, and you are using the 0.229.

 

(To everyone else: You must upgrade to 0.230 (when it becomes available) if you ever intend to use the IDE card in the Geneve emulation.)

Well, if you are able to upload an interim version, then I can give the IDE testing a good workout before the official release of .230.  I have vacation time I have to burn off before March 31, and I am taking time off Friday, and will not have to be back to work until Thursday 4/1.  I can use some of that time to give the code a good workout with the changes to see if there are any problems since I do not have real iron with the IDE.

 

Beery

 

[+mizapf]

Ok, then try this: https://ftp.whtech.com/emulators/MAME/ti99/windows/mame20210324b_ti99_win64bit.zip

 

I guess it suffices to replace the older mame.exe file by the file in this zip.

[+9640News]

OK, great news.  With the update, things are working.  I did have to turn off Genmod decoding for the IDE which doesn't make obvious sense when I have a Memex installed.

 

Right now, copying from Myarc HFDC to the IDE drive from MDOS mode with GDM2K.  After that, then it will be to copy from IDE drive to HRD for whatever will fit to make sure things are copying well.

 

Beery

 

[+mizapf]

OK, good to hear.

Are you using Genmod? I understood that you used the standard Geneve emulation; the Memex can be used with both Geneve and Genmod. The Genmod decoding only works when AME and AMD are under control of Genmod, which was the reason why the IDE card failed to work on the standard Geneve.

[+9640News]

10 minutes ago, mizapf said:

OK, good to hear.

Are you using Genmod? I understood that you used the standard Geneve emulation; the Memex can be used with both Geneve and Genmod. The Genmod decoding only works when AME and AMD are under control of Genmod, which was the reason why the IDE card failed to work on the standard Geneve.

I am set as shown below.  I thought I was, but now that I think of it, I need to specify genmod instead of geneve on the command line, correct?

 

[+mizapf]

Yes, the Genmod emulation includes the Genmod daughterboard and requires the genmod.zip ROM.

[+InsaneMultitasker]

4 hours ago, 9640News said:

Right now, copying from Myarc HFDC to the IDE drive from MDOS mode with GDM2K.  After that, then it will be to copy from IDE drive to HRD for whatever will fit to make sure things are copying well.

This is great news. Did you partition the drive into IDE1-4?  If not, it would be beneficial to test this and confirm that IDE1 (via SCSMAP) still functions. If it works as expected, then I will implement additional mappings within the low level DSR code this weekend, so that you can map  unit/device numbers  IDE2-8.   This will be consistent with the existing mapping of SCSI IDs 0-6.  The OS will continue to use SCSx as the generic device name for SCSI, IDE, and RamHD devices within the master DSR. 

[+9640News]

8 hours ago, InsaneMultitasker said:

This is great news. Did you partition the drive into IDE1-4?  If not, it would be beneficial to test this and confirm that IDE1 (via SCSMAP) still functions. If it works as expected, then I will implement additional mappings within the low level DSR code this weekend, so that you can map  unit/device numbers  IDE2-8.   This will be consistent with the existing mapping of SCSI IDs 0-6.  The OS will continue to use SCSx as the generic device name for SCSI, IDE, and RamHD devices within the master DSR. 

After getting the DSR installed, I went into DU2K and Initialized the disk.  I did not change any of the partitioning. 

 

The existing partitioning looks like what is shown below.  Let me know what you want changed and the new offsets/size, and I will test.

 

 

 

 

[+9640News]

Michael,

 

So far, using MAME with a HRD 4000B (8MB), HFDC, and IDE, all is playing well together.  Still need to do some more testing.

 

I did look at the PFM 512 and also saw a PFM 512a option.  What are the differences?

 

I found that if I turned PFM 512 on, and Reset the Geneve emulation, MAME did not boot.  I'm guessing the bios for the PFM 512 has not been loaded.  Is there a rom dump needed?

 

 

[+mizapf]

I think Tim can explain better. There is a collection of tools to program the flash memory, in particular to upload a SYSTEM/SYS on the PFM. You have to boot from EPROM, then you can move the switch to the PFM and run the tools. The "a" is the difference between using the flash chip at29c040 or at29c040a.

Edited March 25, 2021 by mizapf

[+InsaneMultitasker]

Assuming the support follows real hardware, the PFM 512 is for the Atmel 29c040 chip and the PFM512a is for the Atmel 29c040a chip.  The only differences in operation are (1) a different chip identification and (2) the chip's internal sector size, 512 and 256 bytes, respectively.

[+InsaneMultitasker]

25 minutes ago, mizapf said:

The "a" is the difference between using the flash chip at29c040 or at29c040a.

I have been testing the Winbond equivalent in real hardware, thanks to @atrax27407, and wonder if that chip could be added as an option?  I have been updating the programming tools and in the process, corrupted my remaining 29c040 chip    because I did not think to use MAME for testing.  I know, shame on me!

[+9640News]

Correct me if I am wrong, but I thought the flashing of the eprom which I do as I am satisfied with various updates to MDOS, only installs SYSTEM/SYS.  It does not add the loader piece of the code each time it updates.  I've got the PFM 384 on my real hardware, and when I first turn on my system, I get a screen display from the PFM.  With MAME, I got a black screen.  Maybe the PFM 512 does things a bit differently, but I did not think so.

 

Beery

[+mizapf]

38 minutes ago, 9640News said:

I've got the PFM 384 on my real hardware, and when I first turn on my system, I get a screen display from the PFM.  With MAME, I got a black screen.

Something pre-loaded on the PFM? There is nothing pre-loaded in MAME, yes.

 

I don't remember all details (some years ago already), but I may have chosen the way to swap the EPROM and the PFM in-system because this is the best way to get to a working PFM. This is similar to the HSGPL which can be loaded in MAME in-system.

[+9640News]

1 hour ago, 9640News said:

Correct me if I am wrong, but I thought the flashing of the eprom which I do as I am satisfied with various updates to MDOS, only installs SYSTEM/SYS.  It does not add the loader piece of the code each time it updates.  I've got the PFM 384 on my real hardware, and when I first turn on my system, I get a screen display from the PFM.  With MAME, I got a black screen.  Maybe the PFM 512 does things a bit differently, but I did not think so.

 

Beery

 

56 minutes ago, mizapf said:

Something pre-loaded on the PFM? There is nothing pre-loaded in MAME, yes.

 

I don't remember all details (some years ago already), but I may have chosen the way to swap the EPROM and the PFM in-system because this is the best way to get to a working PFM. This is similar to the HSGPL which can be loaded in MAME in-system.

It is my understanding, yes, there is something pre-loaded on the PFM when a user first obtains a PFM setup.  Hopefully, @InsaneMultitasker can confirm.  I have seen the source, but stayed away from any testing of it as it could be a royal pain to recover if the loader was overwritten as @InsaneMultitasker indicated above.  Now that I think about it more and had lunch, there is a PFMCORE program that writes the loader from MDOS mode that may be useable once the switch setting on in MAME is enabled.  

 

Beery

 

 

 

 

 

[RickyDean]

1 hour ago, mizapf said:

Something pre-loaded on the PFM? There is nothing pre-loaded in MAME, yes.

 

I don't remember all details (some years ago already), but I may have chosen the way to swap the EPROM and the PFM in-system because this is the best way to get to a working PFM. This is similar to the HSGPL which can be loaded in MAME in-system.

On my pfm+ - 384 system, it had 2 eeproms, the lower one has code on it, that I believe came from Cecure, the upper the system/sys, and other files that I would have loaded, back in the day. I copied the bin's as I took the eeproms off.

[+InsaneMultitasker]

@9640NewsI am thinking that for the initial load, one could start with the EPROM as mizapf describe then once booted, enable the PFM device, and use the two files on the MDOS 6.50 distribution disk to load the core BIOS.   This is done from the MDOS command line as "PFMCOREUP PFMCOREV7" if I recall the filenames correctly. Hopefully I did not try to test for an existing core

 

The operation should complete within a few moments.  Restart and you should see the PFM boot screen.  PFM512's built-in loader is limited to 120K, just like the PFM+.   CYA can install up to 128K.   The standalone code I am finalizing this week will enable the extra 8k needed for the upcoming 136k release.

 

Thinking back, I may have shared a few early versions of my loader with  @mizapf during his MAME development.  The intent is to decouple the system/sys loading from CYA and the device itself, with the standalone utilities. 

[+9640News]

8 minutes ago, InsaneMultitasker said:

@9640NewsI am thinking that for the initial load, one could start with the EPROM as mizapf describe then once booted, enable the PFM device, and use the two files on the MDOS 6.50 distribution disk to load the core BIOS.   This is done from the MDOS command line as "PFMCOREUP PFMCOREV7" if I recall the filenames correctly. Hopefully I did not try to test for an existing core

 

The operation should complete within a few moments.  Restart and you should see the PFM boot screen.  PFM512's built-in loader is limited to 120K, just like the PFM+.   CYA can install up to 128K.   The standalone code I am finalizing this week will enable the extra 8k needed for the upcoming 136k release.

 

Thinking back, I may have shared a few early versions of my loader with  @mizapf during his MAME development.  The intent is to decouple the system/sys loading from CYA and the device itself, with the standalone utilities. 

 

Just to make sure I am on the same page as you, is your code you are finalizing a modification of the PFM 512 built-in loader to permit up to 136K, or a modification expanding CYA from 128K to 136K?  I guess I have been under the impression it was the PFM loader you were modifying however it sounds a bit more like you are modifying CYA for the larger size file???

 

 

 

[+InsaneMultitasker]

22 minutes ago, 9640News said:

I guess I have been under the impression it was the PFM loader you were modifying however it sounds a bit more like you are modifying CYA for the larger size file???

I am not modifying CYA at this time - the 136K OS size requires too much effort for me to tackle it right now. 

 

The standalone program is the go-forward method for both the system loading and flashdisk loading; I have no desire to reverse engineer those features of the PFM devices when a command line utility is much simpler to write and less risk to the flash chips.

 

Oh, and the added benefit and something @Swim has asked me for is to disable the CRC delay.  So PFM should theoretically start 9-10 seconds quicker on powerup, if all goes as planned.

[+9640News]

38 minutes ago, InsaneMultitasker said:

I am not modifying CYA at this time - the 136K OS size requires too much effort for me to tackle it right now. 

 

The standalone program is the go-forward method for both the system loading and flashdisk loading; I have no desire to reverse engineer those features of the PFM devices when a command line utility is much simpler to write and less risk to the flash chips.

 

Oh, and the added benefit and something @Swim has asked me for is to disable the CRC delay.  So PFM should theoretically start 9-10 seconds quicker on powerup, if all goes as planned.

OK, we are on the same page then.

[+InsaneMultitasker]

The PFM512 Atmel 292040 core has been stripped of its product ID test and CRC test, and the BIOS is no longer restricted to a specific chip type.  The final, reserved bank in the chip is now consumed by the OS, and the BIOS loads the entire 136K OS from PFM to memory.  The startup is nearly 10 seconds faster with the removal of the CRC check. 

 

The OS and Flashdisk loaders now detect and program the Atmel 29c040, Atmel 29c040a, and Winbond W29c040 chips.  Tomorrow I'll dig around for the core dump/program source from ~2001. 

 

For the first time in 20 years, old faithful MDOS 6.50 no longer greets me at startup... 

 

[+9640News]

Michael,

 

I have been trying to generate a new Eprom for the Geneve that will allow booting from the IDE.

 

How would I go about using my own Eprom with MAME?

 

Beery

 

[+mizapf]

Two ways:

 

1. You could upload it to the PFM and boot from there.

2. You could replace the file genbt090.bin or genbt100.bin in geneve.zip with your custom ROM. You can select which ROM to boot with the switch -bios 0.98 or -bios 1.00 (yes, don't know why the dump is named 0.90; it'll cause too much fuss if I change that.) However, you will get a warning message that the dump does not match the registered hash, which means it is not a verified official ROM.

 

If we get to a new boot EPROM some day, I'll be happy to add the hashes to the Geneve emulation. Right now you have to replace one of the ROMs, you cannot add another option - unless you change the entries in geneve.cpp.

[+9640News]

5 hours ago, mizapf said:

Two ways:

 

1. You could upload it to the PFM and boot from there.

2. You could replace the file genbt090.bin or genbt100.bin in geneve.zip with your custom ROM. You can select which ROM to boot with the switch -bios 0.98 or -bios 1.00 (yes, don't know why the dump is named 0.90; it'll cause too much fuss if I change that.) However, you will get a warning message that the dump does not match the registered hash, which means it is not a verified official ROM.

 

If we get to a new boot EPROM some day, I'll be happy to add the hashes to the Geneve emulation. Right now you have to replace one of the ROMs, you cannot add another option - unless you change the entries in geneve.cpp.

Thanks for the info.  I had never tried, but I thought those warnings if I replaced it, would result in MAME exiting.

Beery