OoeyGUI v4.0 Released!

[+Vorticon]

On 1/31/2022 at 6:09 AM, mizapf said:

Can you pass the "-log" option via OoeyGui? Just to make sure that there are no error outputs. The output is in error.log.

 

The screen as shown above does not look like having an issue with resolution things; this rather seems like coming from the emulated system.

I'm not aware of a log option for OoeyGui. I tend to agree though that it's unlikely related to the screen resolution. Very odd...

[+Vorticon]

OK I found the problem: if DSK1 had my PHOENIX disk (program in development), it will corrupt the screen. DSK1 apparently has to have one of the p-system disks in it for the emulation to run properly. This happens both with Ooeygui and running directly from mame.

Looking into it further, I noticed that the PHOENIX disk is being reported by linux as being a 360K disk whereas TIDIR reports it as a 720 sector disk or 180K. The p-system cannot read disks higher than 180K (DSSD), so I am assuming this is where the issue lies. 

Interestingly however, Classic 99 does not have any issues with PHOENIX being in DSK1 and likely properly recognizes its size.

I think this is where Michael come in

[+mizapf]

Just by chance, did you try what TIImageTool says to your disk?

 

Why is the P-system unable to read larger disks? Is it limited in terms of the sector number? Or did you use the original TI floppy controller? If the latter is so, you could try another disk controller like the BwG, DDCC1, HFDC, or Corcomp. Basically any other controller. ?

 

[+Vorticon]

5 hours ago, mizapf said:

Just by chance, did you try what TIImageTool says to your disk?

 

Why is the P-system unable to read larger disks? Is it limited in terms of the sector number? Or did you use the original TI floppy controller? If the latter is so, you could try another disk controller like the BwG, DDCC1, HFDC, or Corcomp. Basically any other controller. ?

 

Same results with the BWG and Corcomp controllers.

TIImageTool reports the correct size with 718 sectors.

It is very strange that Linux is recognizing the disk as 360K... I used both the File Manager and Midnight Commander with similar reporting.

As to why the p-system only recognizes up to 180K, that's a question for Anders Persson. I'll post it in the Pascal thread and see what his response is.

[+Vorticon]

So it looks like the p-system can indeed use 360K disks if coupled with an appropriate controller. So not sure what's going on here.

 

[Shift838]

4 hours ago, Vorticon said:

So it looks like the p-system can indeed use 360K disks if coupled with an appropriate controller. So not sure what's going on here.

 

can you send me the disks you are using.

 

 

[+Vorticon]

1 hour ago, Shift838 said:

can you send me the disks you are using.

 

 

Here you go.

Phoenix.dsk

EDT-COMP.dsk

[Shift838]

1 hour ago, Vorticon said:

Here you go.

 

What files are in the PASCAL file on the phoenix disk?

 

 

[+mizapf]

TIImageTool says it is a DSSD disk (180k) because the disk says so in its volume information block (9 sectors/track). However, there is content in sectors 720+.

 

00000000: 5048 4f45 4e49 5820 2020 02d0 0944 534b  PHOENIX   ...DSK
00000010: 2028 0201 0000 0000 0000 0000 0000 0000   (..............
00000020: 0000 0000 0000 0000 0000 0000 0000 0000  ................

 

0x02d0 = 720 sectors

09 sectors/track

20 = protection (none?)

28 = 40 tracks

02 = sides

01 = density

 

So the VIB does not match the actual contents.

[Shift838]

@VorticonI get the same issue you are seeing with your Phoenix disks.  However, if I run it on Classic99 with the P-Code option then it boots up.

[+mizapf]

I just tried to run the Phoenix disk with the P-Code card in MAME, and right at the start, the output on the console reveals something interesting, maybe crucial.

 

./mame ti99_4a [...] -ioport:peb:slot4 pcode -flop1 ~/Downloads/Phoenix.dsk  
[ti99_dsk] Warning: Disk image size does not correspond with format information in VIB.
[ti99_dsk] Floppy disk has too many tracks for this drive, will skip every second track.

 

Maybe I should try to fix the format autodetection at this point. The thing is that the format adapter tries to guess the geometry, as sector dumps do not reveal their geometry by the file size or structure. 

 

This is not so easy as it seems ... imagine an 80-track DSSD disk: It has 80 tracks with 9 sectors/track and 2 sides, which means 1440 sectors, or 360K. A 40-track image with 18 sectors/track has the exact same size. So how shall I decide what format to use? I'm taking the VIB information. However, in this case, the confusion starts right there.

 

It finds the entries in the VIB, but they contradict the file size; either the number of tracks is bad, or the number of sectors per track. It seems as if I took the number per sector (9) to calculate the number of tracks, which is 80 (80*9*2 = 1440 sectors = 360K). However, the 525dd drive cannot handle 80 tracks, so it says that it will skip every second track. This will not end happily.

I'll try what happens if I fix the VIB.

 

Edit: If I modify the VIB to define a DSDD disk, the screen looks different (if phoenix.dsk is in your DSK1 drive); but still messed up. All characters are redefined, including space. Also, the PASCAL file still has 718 sectors; not sure whether this must be fixed as well.

[+Vorticon]

I wonder if the Phoenix disk image is corrupted somehow even though it seems to work fine in Classic99. I'm going to try to copy it over to a real disk tonight using Fred Kaal's DSK2PC program and an HDX-modified RS232 card and see if I can replicate the issue.

[+mizapf]

I hope you never put the DSK image into a 35dd drive in MAME. This would be a possible effect; the 35dd drive has 80 tracks, and when writing, would attempt to spread the image over 80 tracks. This would double the image size without adapting the VIB.

 

Interesting: This is the contents of the VRAM shortly before loading stops, and after the screen became garbled. The screen image table seems to be filled with a program.

[+Vorticon]

Well I transferred the Phoenix disk image to a real disk (sector based) and it worked just fine on a real p-system. 

And no, I just used the standard disk controller in Mame initially.

[+mizapf]

I'm not too surprised that it works in a real machine. Mind that this is obviously a problem of the disk image format recognition, whereas the real system has its real floppy disk. What I referred to was the usage of the 80-track "35dd" disk drive, not the controller. I guess if you did not think about that, you did not change it, which means you always used "525dd" 40-tracks.

 

However, I could still need some information to find out whether there is a deeper problem that is worth investigating. In fact, I found two bugs in the p-code card emulation concerning the debugger (forgot a return, and used the wrong variable; no effect for normal use).

 

- What disk controller do you use on your real system? Can it cope with 360K disks?

- Can you create a different format, like PC99 (track dump) or HFE (Lotharek/Gotek)? Those are not prone to format misdetection.

[+mizapf]

Should it end with "Welcome PHOENIX, to U.C.S.D. p-System IV.0,..."? This is what I get from the attached DSK image. I actually clipped off the higher 180K.

Phoenix2.dsk

[Shift838]

1 hour ago, mizapf said:

Should it end with "Welcome PHOENIX, to U.C.S.D. p-System IV.0,..."? This is what I get from the attached DSK image. I actually clipped off the higher 180K.

Phoenix2.dsk 180 kB · 0 downloads

i can verify this new image works within MAME.  @Vorticonneeds to test too

[+Vorticon]

23 hours ago, mizapf said:

I'm not too surprised that it works in a real machine. Mind that this is obviously a problem of the disk image format recognition, whereas the real system has its real floppy disk. What I referred to was the usage of the 80-track "35dd" disk drive, not the controller. I guess if you did not think about that, you did not change it, which means you always used "525dd" 40-tracks.

 

However, I could still need some information to find out whether there is a deeper problem that is worth investigating. In fact, I found two bugs in the p-code card emulation concerning the debugger (forgot a return, and used the wrong variable; no effect for normal use).

 

- What disk controller do you use on your real system? Can it cope with 360K disks?

- Can you create a different format, like PC99 (track dump) or HFE (Lotharek/Gotek)? Those are not prone to format misdetection.

My system has a standard TI disk controller.

I tested the Phoenix2 disk image and that works perfectly without any corruption and it is reported properly as 180K by Linux.

However, it would crash Mame if I used it with the standard TI controller, but not with the BWG or Corcomp. So there is still something funky going on here. 

[+mizapf]

I'll check that.

[+mizapf]

I just tried with the TIFDC as disk controller, but there is a "Welcome PHOENIX" after about 35 seconds here, so no signs of a crash. How does the crash look like?

 

[+Vorticon]

Actually that was a user error. I dropped the Phoenix2 disk in the wrong directory.

So what did you have to do to fix the disk?

[+mizapf]

dd if=Phoenix.dsk of=Phoenix2.dsk bs=256 count=720

 

Copy the first 720 blocks of size 256 from the first into the second file. This is a radical cut that throws away everything after sector 720.

 

Edit: dd is also available for Windows, and can be a really useful tool now and then. Remember: dd stands for "convert and copy", but the abbreviation "cc" was already in use for the c compiler.

[Shift838]

On 2/4/2022 at 2:51 PM, mizapf said:

dd if=Phoenix.dsk of=Phoenix2.dsk bs=256 count=720

 

Copy the first 720 blocks of size 256 from the first into the second file. This is a radical cut that throws away everything after sector 720.

 

Edit: dd is also available for Windows, and can be a really useful tool now and then. Remember: dd stands for "convert and copy", but the abbreviation "cc" was already in use for the c compiler.

what is a good procedure for creating a disk for use in MAME for the UCSD p-code?

 

I have created diskettes in both TIIMAGETOOL and TI99DIR for 90k, 180k and 360k (all in a 5.25 drive with MAME).  Then when I load up the DFORMAT program to prepare the disk the disk gets prepared but now, no matter if I select DS/SD or DS/DD within the tool it changes the disk to 90K SS/SD.

 

Am i doing something wrong?

 

 

[+Vorticon]

6 hours ago, Shift838 said:

what is a good procedure for creating a disk for use in MAME for the UCSD p-code?

 

I have created diskettes in both TIIMAGETOOL and TI99DIR for 90k, 180k and 360k (all in a 5.25 drive with MAME).  Then when I load up the DFORMAT program to prepare the disk the disk gets prepared but now, no matter if I select DS/SD or DS/DD within the tool it changes the disk to 90K SS/SD.

 

Am i doing something wrong?

 

 

From Anders:

 

Yes, there is a bug. If I remember correctly now it can't format double sided, although it claims it can. But it can do double density, although TI's card doesn't support that.
Workaround is to format, using any disk manager you may have, within the standard operating system. You can use the Disk Manager II module or whatever.
Then, when you are in the p-system, you go to the Filer and use the Zero command to install a fresh p-system directory on the disk. Tell it that you have 180, 360 or 720 blocks on your disk, for 90/180/360 kbytes.
Then it works.
I have made a DFORMAT program that does work. It will also use the interlacing to give best performance with the p-system, if you have a CorComp controller. I've never tested it with a Myarc, though. I don't have any.

[Shift838]

10 hours ago, Vorticon said:

From Anders:

 

Yes, there is a bug. If I remember correctly now it can't format double sided, although it claims it can. But it can do double density, although TI's card doesn't support that.
Workaround is to format, using any disk manager you may have, within the standard operating system. You can use the Disk Manager II module or whatever.
Then, when you are in the p-system, you go to the Filer and use the Zero command to install a fresh p-system directory on the disk. Tell it that you have 180, 360 or 720 blocks on your disk, for 90/180/360 kbytes.
Then it works.
I have made a DFORMAT program that does work. It will also use the interlacing to give best performance with the p-system, if you have a CorComp controller. I've never tested it with a Myarc, though. I don't have any.

Would you like to share your DFORMAT program ?