Jump to content
IGNORED

New MAME release


mizapf

Recommended Posts

The only unexpected thing I noticed is that it does not issue an error for DSK2 and DSK3; just treats it like the same drive DSK1. The same is true for HEXBUS.102 and HEXBUS.103.

 

Fixed. I forgot to wire the CRU latch to the DS lines, and instead hardwired DS0 to 1.

  • Like 3
Link to comment
Share on other sites

  • 1 month later...

I guess I need some remedial help. :)

 

For a long time, I've been using MAME 0.185. I downloaded 0.197 in anticipation of playing with the disk emulation in the 99/8 and I think I even downloaded what I thought was the newest ti99_8.zip file but when I add the hexbus drive as a slot device, it says it can't find some .u## files and I'm guessing I am missing a ti_hx5102.zip file. I have not been able to find this file anywhere. Help?

 

Thanks!

Link to comment
Share on other sites

Also, as you see, I added a "pre-xxx" folder where you can find ROMs for older releases. In the case there is another change (which I don't see right now for short or medium term), I will set up another one and put the current dumps there.

  • Like 2
Link to comment
Share on other sites

... I am missing a ti_hx5102.zip file. I have not been able to find this file anywhere. Help?

 

To some extent, from the MAME view, what you experienced is not unwanted. In fact, in many countries, it is legal to dump a ROM to create a backup. The idea is that MAME will execute your dumps; but MAME does not help you to find those dumps on the net. This is done to ensure that we don't drift into illegal terrain.

 

We're here in our small TI community, and I am speaking as a TI computer user, not as a MAME dev, when I recommend some FTP server to download the dump from. Anyway, with respect to the 99/8, we have consent from TI to distribute the ROMs, so there is no need to worry.

 

If you wondered why we changed the ROM dumps some time ago, it may be better understandable when you consider the above idea. Typically, you would pull out or unsolder the ROMs, read them by some device, and dump them to files. Then you drop them into your MAME rompath, and MAME will check the dump for errors by using a CRC and an SHA1 fingerprint.

 

Earlier, we had all ROMs in a single ROM file (or two, ROM and GROM). With 0.174 I changed the ROM dumps in the way that we had to split the single ROM dump file to one separate dump file per circuit.

 

Imagine in the current situation, going for the "ideal" MAME scenario, if you had a real HX5102, and you wanted to run the MAME emulation, you would probably open its case, pull out its ROMs, dump them to files, and copy them to the rompath. MAME even tells you how to name the files.

 

I agree that this meant quite some hassle for people who had the full dumps before and noticed that MAME stopped working with them. However, considering the idea from above, I think this change made sense.

  • Like 1
Link to comment
Share on other sites

It looks like we’ll need to change the cartridge format, or I’m doing something wrong. Any attempt to mount a cartridge in any of the TI 99 emulations causes a message saying that the ROM is missing something.

 

If I start the 99/8 emulation and mount the hexbus floppy drive (which it now can find) none of my existing disk images will load any files (I think I get I/O ERROR 07 but I will check when I am home). An attempt to create a new disk image inside MAME just causes MAME to crash.

 

I feel like I’m *so close* ! :)

Link to comment
Share on other sites

You don't use double density, do you? Double density is not supported yet on the HX5102 because the format differs (16 sectors).

 

How do you create a new disk image in MAME? In the OSD menu or with imgtool? I'd really recommend you use TIImageTool for that.

 

Also, please copy the error messages to your post; this will really make it simpler to find out the cause. If you just say it crashes, I cannot see what happened.

Link to comment
Share on other sites

I seemed to resolve my issues except for the creation of a new disk image.

 

The I/O Error 07 I was getting happened when I was trying to load Factor Foe and Tic Tac Toe. Once I verified that Disk Manager 2 was able to catalog the disk, I knew the emulation could read my disk image correctly. CALL FILES(1) / NEW allowed the programs to load. After that, every time I load it worked successfully, whether I did a CALL FILES or not. I'm not sure what I did to fix it, but it's working fine now.

 

Typically if I want a new blank disk I just copy an existing disk and then format it with Disk Manager, but when I couldn't get any of them to work, I tried to create one through the OSD menu. This is what happens when I do that:

 

1. I enter in the disk name and extension.

2. I selected TI99 sector dump floppy disk image.

3. MAME immediately quits with no error message.

 

The same behavior occurs if I pick TI99 track dump floppy disk image, except I get a prompt first from Windows saying that MAME has stopped working.

 

I found this error message in the windows application log:

Faulting application name: mame64.exe, version: 0.197.0.0, time stamp: 0x00000000
Faulting module name: msvcrt.dll, version: 7.0.16299.125, time stamp: 0x20688290
Exception code: 0xc0000005
Fault offset: 0x00000000000732cf
Faulting process id: 0x1668
Faulting application start time: 0x01d3e32d93290f32
Faulting application path: C:\mame0197\mame64.exe
Faulting module path: C:\WINDOWS\System32\msvcrt.dll
Report Id: b1d217df-31e2-40a9-bb03-f6365ce2f782
Faulting package full name:
Faulting package-relative application ID:

 

Not sure how helpful that is, but that's what I've got.

 

Thanks for all your hard work with MAME!

Edited by Casey
Link to comment
Share on other sites

This is fantastic. Great work, and thank you for seeing this through.

 

Naturally, I wanted to see if I could get my Pascal game running on the 99/8. I loaded up (a copy of!) my program disk, booted into the p-system, and it was clearly able to read the disk. It loads the compiled game, but errs out with a "unit SUPPORT not found" message. I'm familiar with that. My program requires some system libraries such as Sprite and Support, and given the diskette size limits I look for those libraries on a second disk. That means my game needs 2 disks: a master Pascal disk in the first drive, and the game disk in the second.

 

Adding a second drive to the hexbus has me stumped. I tried using the same nomenclature as with the PEB, and added -flop2 [path/diskvol.dsk] but I get an error message, "unknown option -flop2". I tried a few different combinations, to no avail. I'm obviously missing something, but I'm not sure what.

 

By way of example, this works:

mame64 ti99_8 -hexbus hx5102 -flop1 disks\pmaster.dsk

 

as does

 

mame64 ti99_8 -hexbus hx5102 -flop1 disks\gamed.dsk

 

But this does not

mame64 ti99_8 -hexbus hx5102 -flop1 disks\pmaster.dsk -flop2 disks\gamed.dsk

 

I know I'm missing something obvious, it's just not obvious to me. Maybe it's just too late in the day and I'm getting crosseyed.

 

One thing I did learn: the utilities for the 99/4A p-code seem to work on the 99/8. My pmaster.dsk contains the 99/4A version of the editor and filer, both of which appear to run on the 99/8. I'm pretty sure these were updated for the 99/8, but I don't know that I've seen the disk images anywhere. Do the 99/8 versions exist, and have they been captured? If they have, I'd like to try out the 99/8 as a Pascal development environment.

 

But first, I gotta get more than one drive working! That's a configuration - well, more likely, an operator error - problem.

Link to comment
Share on other sites

But this does not

mame64 ti99_8 -hexbus hx5102 -flop1 disks\pmaster.dsk -flop2 disks\gamed.dsk

 

I know I'm missing something obvious, it's just not obvious to me. Maybe it's just too late in the day and I'm getting crosseyed.

 

The "obvious" thing is that there is only one drive in the HX5102. You cannot insert two disks into one HX5102. :)

 

Some points:

 

1. Do you really need two floppy drives in reality to use Pascal? Two HX5102?

2. Wouldn't it work by swapping the disks during runtime, using the OSD?

3. The HX5102 has an internal connector for another disk drive. This is currently not emulated, but it would be possible, and not too difficult (similar to the existing floppy controllers).

4. The Hexbus is designed to build a chain of devices. I wrote the Hexbus emulation to support that, but this is untested. Also - same as in real life - you would need to configure the second drive in the chain to be DSK2 or HEXBUS.102. This is currently not emulated.

 

So the easiest remedy is number 3. However, please check option 2 first.

Link to comment
Share on other sites

Typically if I want a new blank disk I just copy an existing disk and then format it with Disk Manager, but when I couldn't get any of them to work, I tried to create one through the OSD menu. This is what happens when I do that:

 

1. I enter in the disk name and extension.

2. I selected TI99 sector dump floppy disk image.

3. MAME immediately quits with no error message.

 

I'll check that. I did not pay too much attention on the internal disk creator which is somewhat limited and not very user-friendly. For that reason I wrote the TIImageTool.

Link to comment
Share on other sites

 

I'll check that. I did not pay too much attention on the internal disk creator which is somewhat limited and not very user-friendly. For that reason I wrote the TIImageTool.

Don't spend too much time on that. Especially if there are other/better options.

Link to comment
Share on other sites

The 99/8 version of the p-System is 4.11. I have a set of the disks for it--in 16-sector double-density format. I do need to take those and copy them to a disk image though. . .I just need to find the necessary time to do so.

If you read them by a Kryoflux, they would immediately work in MAME. The current thing for me to do is to include the 16-sector format in the sector dump format, and since the conversion goes via the track dump format, I'll also have to define a suitable layout here. That is, HFE would be OK, DSK not yet.

  • Like 1
Link to comment
Share on other sites

Don't spend too much time on that. Especially if there are other/better options.

 

Fixed it; there were actually two separate glitches. Still, I strongly recommend to use TIImageTool to create new images, because with the OSD you only get unformatted images.

  • Like 1
Link to comment
Share on other sites

 

The "obvious" thing is that there is only one drive in the HX5102. You cannot insert two disks into one HX5102. :)

 

Some points:

 

1. Do you really need two floppy drives in reality to use Pascal? Two HX5102?

2. Wouldn't it work by swapping the disks during runtime, using the OSD?

3. The HX5102 has an internal connector for another disk drive. This is currently not emulated, but it would be possible, and not too difficult (similar to the existing floppy controllers).

4. The Hexbus is designed to build a chain of devices. I wrote the Hexbus emulation to support that, but this is untested. Also - same as in real life - you would need to configure the second drive in the chain to be DSK2 or HEXBUS.102. This is currently not emulated.

 

So the easiest remedy is number 3. However, please check option 2 first.

 

FWIW, I neglected to mention that I had tried -hexbus hx5102 twice on the command line with no success, so I thought maybe it would chain as it does on the PEB.

 

About the p-system and drives, yes it is possible to use with a single drive, but it is a pretty big hassle. On the 99/4A, TI recommended 2 drives at a minimum. It's a lot of disk changing with only one. I'll fuss around with this just for sake of getting my game to run on the 99/8 (it is kinda cool), but with one drive it will not be functional as a development environment.

Link to comment
Share on other sites

I guess you tried "-hexbus hx5102 -hexbus hx5102". This won't work. Instead, the Hexbus is offered again as a slot option of the first hx5102. Accordingly, the line should read

 

"-hexbus hx5102 -hexbus:hx5102:hexbus hx5102"

 

But as I said, you would need to configure the second hx5102 as DSK2, which is not emulated right now.

Link to comment
Share on other sites

OK guys, good and bad news. Which one first?

 

OK, bad news first. There is a serious issue with double-sided disks on the HX5102. As long as you stay on side 1, everything is good. However, none of the sectors past 359 are reached (you hear the head desperately seeking). I already suspected something like that when I used the "format disk" utility in the Pascal section. It formats side 1, restores (pulls back the head to track 0), then formats side 2. This would mean that the track sequence had changed for that drive on side 2, and no double-sided disks from the 99/4A world work here. Even worse, you will break them when you write to them.

 

That is, you users of the real HX5102, can you confirm problems with double-sided disks on the HX5102?

 

There is still a chance that I did something wrong. However, it would not be so trivial like the track sequence in the image file. When the floppy needs to read sector 360, it pulls back the head. A normal TI floppy would move the head towards the spindle. Pulling back the head is hardcoded in its ROM and cannot result from reading the disk, because the information on the disk used linear block addressing (0..719) and not CHS addressing (cylinder, head, sector).

 

Are you still here for the good news?

 

I managed to add a second drive to the hx5102 device. This is just like connecting another drive to the connector in the real HX5102.

 

 

./ti998 -hexbus hx5102 -hexbus:hx5102:d1 525dd -flop1 disks/tests/ti998.dsk -flop2 disks/tests/ti998testdssd.dsk

 

You see that you have to add a floppy drive to the "d1" connector. The "d0" connector is by default connected to the first drive. The screenshot shows that I cataloged drive one, then loaded a file that is obviously not on that disk but on disk 2.

 

 

 

 

 

post-35000-0-08944900-1525523035.png

  • Like 5
Link to comment
Share on other sites

There is still a chance that I did something wrong.

 

Yes, I'll take that chance. I'd prefer to find those bugs more easily than starting to read through the disassembled code, in the end it was that simple: The drives were configured for 77 tracks because I swapped the meaning of 0 and 1 for the track count (and by the first simple tests, this error slipped through). On that occasion, I added DIP switches to the configuration, with 40 tracks being the default.

 

This explains my observation: The floppy head was pulled back not because the track is at the outer rim, but because it failed to step to track 40 (highest is 39), then tried to recalibrate several times. Tests showed that I can now read from sectors higher than 359, and also write to them without breaking the image.

 

Already commited to Github; do a git pull, or wait for the end of May.

Edited by mizapf
  • Like 2
Link to comment
Share on other sites

Great news Michael!

Sorry that my devices are currently not that ready to test things for you. My two desks are stuffed with stuff from the Ds990, which we are still trying to get to work. I was on the TI topic the whole weekend. Simply with other things. Trying out my first oscilloscope, tracing wires on the DS990 processor card to document it, reassembling one 99/4A, dissassembly and analyze of the 99/4,...

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...