Geneve - Stock Market Program $$CRASH$$

[+9640News]

Also, another note: If you want to work with 80-track images in MAME, you must specify that you want to use an 80-track floppy drive. Or, in other words: You cannot read 80-track images with 40-track drives (surprise :-) ).

mame64 geneve -peb:slot8 hfdc -peb:slot8:hfdc:f1 35dd ...

Beware - if you work with an 80-track drive in MAME, your 40-track images will become unreadable on 40-track drives once you write to them.

 

The safest bet is still DSDD40.

OK. One of my purposes with that 1.44 MB image was so that everything is all together in one neat little file as it exceeded DS/DD capacity.

 

I understand the HFDC needs to be configured in MAME and/or MESS for 80 tracks. However, how does 40 track images become unreadable? I thought they were straight sector dumps. Is sector 0 being modified of a 40 track disk to think it is in an 80 track drive or is there something being appended to the file, etc.?

 

Trying to understand the changes.

 

I understand what is going on with HFE images. Just trying to understand what is going on with the DSK images.

 

Beery

 

Beery

[+mizapf]

I'm currently preparing an illustration of the internals of MAME's floppy system, also because of your question related to in-memory processing. For now I can say that the sector dump of DSK is converted interally to a track dump, then to a flux sequence, which is eventually presented to the emulated controller chip. At commit time it is going in the opposite direction.

 

The point is that a 40-track image allows for two steps of the drive to settle on the same medium track. That is, you restore the drive, read track 0, then do a track step, and you will read the same track 0, then do another step, read track one, another step, again track 1, and so on. In order to work with such a drive, you have to apply double-stepping for 40-track media.

 

However, this double stepping does not make the head twice as wide. So when you write a track, only one half of the track will be modified. Overwriting the second part of the track in the exact way of the first, perfectly aligning the flux changes, is impossible. Typically this will lead to making such a medium unreadable in a normal 40-track drive later (or you'll have to be very lucky that one of the drives is misaligned).

 

In order to allow for this double stepping in MAME, I read the DSK sectors, create a track in memory, and then create an exact copy of that track in memory as the next track. This should adequately model the real situation. That is, the 40-track image becomes an 80-track image internally. When commit time has come (exit the emulator or change the disk), the tracks are written back, but now we have 80 tracks, and the image will become twice as large. So next time when you want to read that image, everything is fine, since your changes are on the expected tracks, while every second track will contain old data from the earlier 40-track handling.

 

80 tracks are typically used by 3.5" drives, while most 5.25" drives use 40 tracks.

[+9640News]

I'm currently preparing an illustration of the internals of MAME's floppy system, also because of your question related to in-memory processing. For now I can say that the sector dump of DSK is converted interally to a track dump, then to a flux sequence, which is eventually presented to the emulated controller chip. At commit time it is going in the opposite direction.

 

The point is that a 40-track image allows for two steps of the drive to settle on the same medium track. That is, you restore the drive, read track 0, then do a track step, and you will read the same track 0, then do another step, read track one, another step, again track 1, and so on. In order to work with such a drive, you have to apply double-stepping for 40-track media.

 

However, this double stepping does not make the head twice as wide. So when you write a track, only one half of the track will be modified. Overwriting the second part of the track in the exact way of the first, perfectly aligning the flux changes, is impossible. Typically this will lead to making such a medium unreadable in a normal 40-track drive later (or you'll have to be very lucky that one of the drives is misaligned).

 

In order to allow for this double stepping in MAME, I read the DSK sectors, create a track in memory, and then create an exact copy of that track in memory as the next track. This should adequately model the real situation. That is, the 40-track image becomes an 80-track image internally. When commit time has come (exit the emulator or change the disk), the tracks are written back, but now we have 80 tracks, and the image will become twice as large. So next time when you want to read that image, everything is fine, since your changes are on the expected tracks, while every second track will contain old data from the earlier 40-track handling.

 

80 tracks are typically used by 3.5" drives, while most 5.25" drives use 40 tracks.

 

Michael,

 

I understand what you are saying. So, I do have a few questions and comments.

 

As a MESS and when a decent UI is developed for MAME, I will likely be a MAME user. Just not ready to commit to that jump as what I have, it works less that one graphics bug just fixed, and I know how to use it and I do not have to figure out all the command line arguments.

 

As far as your changes though. Here are my questions. It sounds like you are really going the direction of PC99 capturing (or creating) all the between sector information of a disk. If that is the case, I hope the direction you are going would go in the direction of being compatible with PC99 dsk images. And if you are going in that direction, track copiers or formatting utilities for both the TI and Geneve (HyperCopy) would work. That would be a positive standardizing all DSK images.

 

So, if I understand things correctly, a user should be able to use any disk manager they desire and be able to format?

 

Finally, I hope there is someway the original DSK image can be preserved, perhaps anything with a DSK extension is not updated and anything with a .PC99 extension is updated.

 

Just thinking out loud here as the community has been using these DSK images and there are thousands of these files that people will question which emulator loads which image.

 

Beery

 

 

I would hope a utility program could be written assuming the above is the case that could allow a user to specify a selected group of DSK images and convert them to this newer format.

 

What about hard drive images? Is anything going to change with those?

[+mizapf]

Hi Beery,

 

pc99 images are supported in the TI MAME emulation for a long time. I suggested to use the suffix "dtk" instead of "dsk", but "dsk" is also accepted, since all pc99 format images use that suffix.

 

Some more points to note:

• The floppy controller emulation (wd17xx) and the flux-level system are not written by me. These are MAME core features designed and written by another developer. I wrote the HDC9234 emulation with the wd17xx as a blueprint, though. Please remember that I am only a small contributor in MAME with a special focus on the TI systems; many things that you learn about are evolutions of the MAME framework that I have no (or minimal) control of. I typically react to changes in the core to keep our emulations running.
• No format is changed into another format. On your host file system, DSK stays DSK, DTK stays DTK, and HFE stays HFE. The point is that during MAME runtime, all three end up internally in the same flux level representation. The only change occurs right for the above scenario, when you use 40-track images in 80-track drives. When the operations have been completed and the emulation is stopped, the whole conversion pipeline is run backwards.
• All programs exploiting specific disk controller features up to reading a full track are supported ... now. Try them. If they don't work, please report this as a bug to me.
• Hard disk images are supported as CHD files, but only as HFDC hard disks, since I don't have an emulation of a SCSI controller yet.

 

Again, and please consider this as a suggestion, not demanding anything from you : I can only discourage anyone to stay with old releases. If bugs are found and fixed, I cannot and will not backport them, so you may once encounter a situation where you are forced to do a big release jump forward, maybe with a bunch of needed adaptations on your side. Second, there are some achievements that happened in the meantime like the PFM+ emulation, and I certainly hope that people do make use of it some time.

 

Adaptations to the current release are minor, and they are a one-time task. You edit your startup scripts or batch files and don't look inside after that for a long time. The most significant changes in the command line are the explicit implementation of the I/O port as a component in the TI, which does not even apply to the Geneve.

[+9640News]

Thanks Michael. I really do appreciate your work and please excuse my ignorance for not knowing MAME already supported the PC99 as well as the HFE extensions of image files. It has only been the last 2 to 3 months that I have become a regular visitor of Atariage as I had just occasionally monitored the Yahoo group from time to time. It is only of late I have been able to become re-engaged back to the TI. A lot has happened so I am still learning some of the finer more "recent" details.

 

If I may trouble you, let me ask for myself and on the behalf of potentially others, if you could construct the command lines for the following two configuration for MAME's latest release:

 

First batch line/file:

 

Geneve

RS232

Memex (2 MB)

Myarc HFDC with 3 HD images (Bootdisk1.HD, Bootdisk2.HD Bootdisk3.HD)

Myarc FDC with Floppy Drives with 4 DSK images (DSDD1.dsk, DSDD2.dsk, DSDD3.dsk, DSDD4.dsk)

9938 VRAM 192K

 

Second batch line/file:

 

Geneve

RS232

Memex (2 MB)

Myarc HFDC with 3 HD images (Bootdisk1.HD, Bootdisk2.HD Bootdisk3.HD)

Myarc HFDC with Floppy Drives with 4 DSK images (DSDD1.dsk, DSDD2.dsk, DSDD3.dsk, DSDD4.dsk)

9938VRAM 192K

 

I understand the HFDC can do floppies, however, to test out a program like HyerCopy, it is only compatible with the TI/Myarc/CC FDC's and not the Myarc HFDC.

 

Thanks.

 

Beery

[+mizapf]

Hi Beery,

 

no need to be sorry. Things did change, and to get an overview over the changes, just have a look at https://www.ninerpedia.org/wiki/MESS_version_history .

 

The DDCC-1 from Myarc is not yet emulated. You have to use the HFDC, but unlike its real counterpart, it is in fact fully reliable. I did not emulate the data separator, actually.

 

Currently, only 128 KiB is available for VRAM. This is the standard Geneve configuration; we did not have a requirement for 192K yet.

 

 

mame64 geneve -peb:slot4 memex -peb:slot5 tirs232 -peb:slot8 hfdc -peb:slot8:hfdc:h1 generic
    -peb:slot8:hfdc:h2 generic -peb:slot8:hfdc:h3 generic -peb:slot8:hfdc:f3 525dd -peb:slot8:hfdc:f4 525dd
    -hard1 Bootdisk1.HD -hard2 Bootdisk2.HD -hard3 Bootdisk3.HD
    -flop1 DSDD1.dsk -flop2 DSDD2.dsk -flop3 DSDD3.dsk -flop4 DSDD4.dsk

 

You can leave away the floppy images (*.dsk) but not the harddisk images (*.hd), at least you need as many hd images as you set up hard disk drives.

 

We currently have two disk controllers, the HFDC ("hfdc") and the standard SD TI Disk Controller ("tifdc").

[+9640News]

Just a FYI, there are a few programs that use the 192K ram of 9938. One was YAPP that used it, but I a not sure for what. It was a program very similar to Myarc's MyArt. Myself, I have used the extra 64K of VRAM as buffer space in work I have done in the past. It is not critical to anything I am aware for it to be implemented though I know in some of the versions of MESS, and the one I use.

 

Beery

[+9640News]

Thanks for the command string. I will cut and paste when I get home this evening and put it into a batch file.

Thanks.

Beery

[+InsaneMultitasker]

 

Currently, only 128 KiB is available for VRAM. This is the standard Geneve configuration; we did not have a requirement for 192K yet.

 

 

I installed many, many VRAM updates in the 90s. It is a real thing and is used by a number of programs. You just made me realize why FunnelWeb doesn't work the same way in emulation as it does on my real hardware. Duh!

[+mizapf]

Now I remember: I once tried to configure the VRAM for 192 KiB, and it was not effective, at least it was not shown in MEMTEST. Then I reverted it to 128 KiB and forgot about it.

 

I just tried it now, and again, MEMTEST stops at 20000 (128K) for VRAM. I am not sure whether this is a bug in MEMTEST, or whether there is actually an issue in v9938.cpp. Can you confirm that MEMTEST shows 192 KiB VRAM when installed?

[atrax27407]

Simply put. F'WEB uses all of the 192K for various things.

[+InsaneMultitasker]

Be sure to use Memtest 1.1 for the most accurate and consistent results. I can confirm that on my real Geneve, memtest has always functioned properly. At Cecure I used Alexander Hulpke's test program and YAPP to verify the VRAM was functional and visually inspect for artifacts resulting from bad sockets or bad memory.

[+mizapf]

Just checked - it is v1.1.

 

Still, it does not continue past >20000. I added some log output to v9938.cpp, and the strange thing is that the MXC bit of register 45 is never set while MEMTEST is running. This is, however, just that bit that switches VRAM access between base and expansion memory.

 

I guess I will have to write yet another test program on my own. In the course of my 9938 experiments, I wrote several machine programs, so one more won't hurt.

[+InsaneMultitasker]

Just checked - it is v1.1.

 

Still, it does not continue past >20000. I added some log output to v9938.cpp, and the strange thing is that the MXC bit of register 45 is never set while MEMTEST is running. This is, however, just that bit that switches VRAM access between base and expansion memory.

 

I guess I will have to write yet another test program on my own. In the course of my 9938 experiments, I wrote several machine programs, so one more won't hurt.

 

I misread your earlier post as meaning MEMTEST stopped working. Sorry. Yes, on the real Geneve memtest stops at 20000 (128k). Now that you remind me, it is the reason why I used Alexander's program. I'll check my images later as I think I know where to find my copy, otherwise, I believe it is on WHTs FTP site.

[+mizapf]

I just added a config switch to the Geneve emulation to turn on the VRAM expansion.

 

How can I verify that the 192K VRAM is present by using YAPP? I wrote a test on my own, and it seems to work, but I'd like to have another tool tell me the same.

[+9640News]

I'm sure YAPP is on Whtech, but I do not have it on my website. I did have Alexander Hulpke's test program he wrote to confirm any installation of the extra 64K was good. I have attached the file which I believe is an E/A#3 file.

 

Beery

 

 

VRAM192.ARK

[+mizapf]

OK ... with 128K, every third test fails (passed - passed - failed - passed - passed -failed ...), with 192K I get all "passed". Looks good. Time to check in.