MDOS V7.30

[+mizapf]

The MFM throughput is determined by the MFM drive and is typically limited to 5 MBit/s (for a 3600 rpm drive)*. The IDE drive boots much faster on the MAME Geneve emulation, so you see that the drive is the actual bottleneck.

 

*MFM controllers like the HDC9234 on the HFDC are clocked at 10 MHz, so the world cannot be faster for them than 10000000 events per second, which are MFM cells on the platter, and you need 2 cells per bit. 

[+InsaneMultitasker]

4 hours ago, mizapf said:

The MFM throughput is determined by the MFM drive and is typically limited to 5 MBit/s (for a 3600 rpm drive)*. The IDE drive boots much faster on the MAME Geneve emulation, so you see that the drive is the actual bottleneck.

 

*MFM controllers like the HDC9234 on the HFDC are clocked at 10 MHz, so the world cannot be faster for them than 10000000 events per second, which are MFM cells on the platter, and you need 2 cells per bit. 

At 5Mbit/s maximum, what would you consider as the typical maximum theoretical controller throughput?   Obviously, throughput is not anywhere near 5 Mbit/s as that would allow us to load Geneve OS in under one second, if I am thinking about this correctly.

[+mizapf]

5 MBit/s unformatted. We have 32 sectors per track, i.e. 8192 byte or 64 KBit, with a transfer time of 1/60 sec (whole track), so this is 3.9 Mbit/s formatted. However, we have an interleave of 4, so you need 4 revolutions, i.e. the rate is 1/4 or 983 kBit/s. Add some time for head positioning. Finally, the contents must be copied from the buffer SRAM on the HFDC into main memory.

 

I mentioned the loading time in MAME because I adjusted the MFM hard disks to exactly deliver bytes at the raw rate of 5 MBit/s (with all head positioning timings etc), and you really notice how much longer it takes to load GeneveOS. That is, if we put some effort in it, we may have a chance to find out where most of the time is spent.

 

On the other hand, I did not add any timing to the IDE drive, so it shows the speed of a ramdisk.

[+dhe]

mizapf,

  Any chance of adding pfm support to the geneve emulation? I assume since it's 'just' memory it's as 'simple' as just adding the correct addresses and then over laying them with access rules? I'm really not asking of you to embark on a great deal of work, more in just learning how emulation is done.

thanks,

[+InsaneMultitasker]

1 hour ago, mizapf said:

5 MBit/s unformatted. We have 32 sectors per track, i.e. 8192 byte or 64 KBit, with a transfer time of 1/60 sec (whole track), so this is 3.9 Mbit/s formatted. However, we have an interleave of 4, so you need 4 revolutions, i.e. the rate is 1/4 or 983 kBit/s. Add some time for head positioning. Finally, the contents must be copied from the buffer SRAM on the HFDC into main memory

Thank you, Michael.  When I repaired Beery's HFDC some time ago, he sent his DREM unit along so that I could verify that the card and DREM worked together after the repair.  What caught my attention was that the device's throughput was the same speed or slightly slower (at the time) than my 20MB MFM 1/2 height hard drive.  I did not research the DREM to understand why this might be the case.

 

Within the Geneve OS, the SCSI, IDE, and RamHD devices all use the same, common buffering routines - the SCSI even uses one additional, intermediate buffer - so we know that portion of the OS code is not an MFM bottleneck. 

 

That reminds me, I have a few HFDC-specific dumps that you created for me. I'll have to revisit that information as I have since forgotten what we were trying to determine...

 

[+mizapf]

@dheGood news: Enter the OSD menu, machine configuration, step through the options "Boot from".

 

[+InsaneMultitasker]

13 hours ago, mizapf said:

5 MBit/s unformatted. We have 32 sectors per track, i.e. 8192 byte or 64 KBit, with a transfer time of 1/60 sec (whole track), so this is 3.9 Mbit/s formatted. However, we have an interleave of 4, so you need 4 revolutions, i.e. the rate is 1/4 or 983 kBit/s. Add some time for head positioning. Finally, the contents must be copied from the buffer SRAM on the HFDC into main memory.

 

I mentioned the loading time in MAME because I adjusted the MFM hard disks to exactly deliver bytes at the raw rate of 5 MBit/s (with all head positioning timings etc), and you really notice how much longer it takes to load GeneveOS. That is, if we put some effort in it, we may have a chance to find out where most of the time is spent.

 

On the other hand, I did not add any timing to the IDE drive, so it shows the speed of a ramdisk.

Update: 

I spent some time reading and commenting HD.SECTORIOW.  The low level routine flow diagram would be quite difficult to create with all of the code jumps and flag gymnastics.  I suppose speed increases might be possible by changing the physical sector interleave and reading more than one sector (256 bytes) at a time, though the latter is beyond the current OS's capabilities.  And I don't see how interleave would affect DREM access times, even if it affected the electro-mechanical drives.

 

Also, I don't yet see a reason why there was a "need" to update the HFDC memory from 8K to 32K to use CFORM and High Density disks.  The OS doesn't read/write tracks (maximum size 256*34 sectors=8.5Kib) operations and DMA read/write operations are completed one sector at a time.  Is the controller using DMA memory to build the entire track?  I don't think so, the manual suggests otherwise and there is no indication that the OS saves/restores the 8k chip to format a track.  (I'll dig up the MDM5 or CFORM code to look for a few clues) 

[+9640News]

13 hours ago, InsaneMultitasker said:

Update: 

I spent some time reading and commenting HD.SECTORIOW.  The low level routine flow diagram would be quite difficult to create with all of the code jumps and flag gymnastics.  I suppose speed increases might be possible by changing the physical sector interleave and reading more than one sector (256 bytes) at a time, though the latter is beyond the current OS's capabilities.  And I don't see how interleave would affect DREM access times, even if it affected the electro-mechanical drives.

 

Also, I don't yet see a reason why there was a "need" to update the HFDC memory from 8K to 32K to use CFORM and High Density disks.  The OS doesn't read/write tracks (maximum size 256*34 sectors=8.5Kib) operations and DMA read/write operations are completed one sector at a time.  Is the controller using DMA memory to build the entire track?  I don't think so, the manual suggests otherwise and there is no indication that the OS saves/restores the 8k chip to format a track.  (I'll dig up the MDM5 or CFORM code to look for a few clues) 

It's been a long time, but I thought the format command in MDM5 may have needed the 32K chip to format a 1.44 MB floppy.

[+InsaneMultitasker]

18 hours ago, 9640News said:

It's been a long time, but I thought the format command in MDM5 may have needed the 32K chip to format a 1.44 MB floppy.

 

I dug into this a bit more.

 

The 9234 format track command requires 4-5 bytes of external RAM.  There is nothing that I can find in the 9234 manual that suggests more RAM is needed to format the drive.  And if I understand the process correctly, the controller's format command lays down the cylinders and interleaves them as requested;  once the cylinders are written, the data can be written/read (initialized) to determine if any sector errors are present.

 

The MDM5 hard drive format routine formats the cylinder (track) first, then it initiates a 'multiple sector write' command and a 'multiple sector read' command to write 32 sectors the drive then verify them. If CFORM followed this example, it would account for the need for the extra ram when writing >32 sectors/cylinder.  However, there is nothing preventing a format program from reading only one half of the cylinder (16-18 sectors) per iteration at the minor expense of speed. In fact, I wonder if the data write is even necessary; in theory, we should be able to validate the sectors after the format. Is writing/reading each cylinder after the format is a best practice?  

 

To format a floppy, the Geneve OS and 9234 use 5 bytes per track  (5 ID bytes *80 [tracks] * 2 [sides]) for a maximum RAM requirement of 800 bytes.  Unlike the MDM5 hard drive format routine, the Geneve OS does not write data to each track; verification is done by reading one sector at a time (slow!).  I have not (yet) found any evidence to support the need for extra RAM for the HFDC floppy IO.

 

CFORM can format hard drives at 33 and 34 sectors per cylinder, though in practice squeezing more than 32 sectors/cylinder seemed to push the data integrity limits of the drives and/or controller. (Edit: based on customer-reported issues/observations)   Track copiers always try to eek out the most speed and I'm sure tape drive support would have benefited from more DMA RAM, though neither materialized for the HFDC.

 

[+mizapf]

As for the additional sectors being squeezed into the track, this is a common thought but it is not really substantial, as I learned. It is a matter of gap length. The controller does not care what is inside the gaps, and it does not care how long the gaps are, except for the sync gaps which must be 12 or 13 bytes long.

 

The cell width is fixed; that is, you always have the same number of cells on the track, and two cells are one bit, so there is an unformatted capacity that we can talk about. For the usual ST-225 and similar ones, you have 3600 rpm and a cell width of 0.1µs, so you get 166666 cells on the track. This is an unformatted capacity of 10416 byte.

 

Per sector, you have two sync gaps (13 bytes each), IDAM, DAM (1 byte each), sector header (4 bytes), 2 CRCs (2 bytes each), which is 36 bytes. Then you have some inter-sector gap which you can define (say, at least 8 bytes). This means 300 bytes per sector. Thus you can safely put 34 sectors in the track. 35 would be possible with a minimum gap, and 36 would definitely not fit ((256+36)*36 = 10512).

 

There was a similar discussion about the reasons why TI designed its double density format to be 16 sectors/track instead of 18, and I am almost sure that this is a purely mathematical issue, not related to data safety.

[+dhe]

Mizapf,

  Let me try my question again, know that we know PFM has already been implemented.

  What were the steps you needed to take to add PFM in particular, and what do you do to add a piece of hardware in general?

 

[+InsaneMultitasker]

2 hours ago, mizapf said:

There was a similar discussion about the reasons why TI designed its double density format to be 16 sectors/track instead of 18, and I am almost sure that this is a purely mathematical issue, not related to data safety.

Good point.   My 'data integrity' comment was based on customer-reported issues/loss of data after they formatted their drive at 33/34 sectors per track, and subsequent return to normal operation upon reformatting at 32 sectors/track. The simplest, cost-effective customer fix was to say, "don't format to 33 or 34 sectors/track"; I don't recall if the root cause was ever determined.  

[+mizapf]

On 5/31/2021 at 2:06 PM, dhe said:

Let me try my question again, know that we know PFM has already been implemented.

What were the steps you needed to take to add PFM in particular, and what do you do to add a piece of hardware in general?

The answer would require me to elaborate on the MAME development process. If you are interested in contributing, please send me a private message.

[globeron]

On 4/19/2021 at 5:32 AM, 9640News said:

Yep, the Rave Speech card needs to be fully decoded for page >3C.  There is a mod out there for that somewhere.  I think Matt was showing us a card with a Rave speech card mod yesterday during the zoom call.

 

 

I might have this issue as well with GPL and Rave Speech Card. As I sometimes see scrambled characters in the GPL blue screen. Always thought some issue with the Horizon card as when I reformatted it and put everything back it looked normal again. Have not tested without the speech card.  Is the Rave Speech card fix an easy one?
 

 

[+9640News]

17 hours ago, globeron said:

 

I might have this issue as well with GPL and Rave Speech Card. As I sometimes see scrambled characters in the GPL blue screen. Always thought some issue with the Horizon card as when I reformatted it and put everything back it looked normal again. Have not tested without the speech card.  Is the Rave Speech card fix an easy one?
 

Mods are pretty simple.  Here are the notes I have from 1994.  I did not figure this out myself, so not sure who sent them to me at the time.

 

The file below is a DV80 file.

GENEVEBC.TXT

[globeron]

Is it possible to map the Horizon RamHD to DSKx. ? Like DSK3 or so that it can be accessed from TImode GPL like in extended basic or EA?

 

with remap 3N or 3F I can only map the RamDSK not the RamHD?

 

[+9640News]

53 minutes ago, globeron said:

Is it possible to map the Horizon RamHD to DSKx. ? Like DSK3 or so that it can be accessed from TImode GPL like in extended basic or EA?

 

with remap 3N or 3F I can only map the RamDSK not the RamHD?

 

As far as I know, all DSKx devices from MDOS mode using the REMAP command are available as the same device number when in GPL mode AS LONG AS YOU ARE NOT USING ROMPAGE MODE!!!!

 

If you partition a Horizon Ramdisk wtih a HD partition, then it maps as a SCSx. devicename and you use the SCSMAP command, not the REMAP command.  And, as long as you do not use ROMPAGE mode in GPL, it too is available in GPL mode.

 

Beery

[globeron]

On 8/23/2021 at 4:03 AM, 9640News said:

Mods are pretty simple.  Here are the notes I have from 1994.  I did not figure this out myself, so not sure who sent them to me at the time.

 

The file below is a DV80 file.

GENEVEBC.TXT 1.88 kB · 9 downloads

 

 

Just wondering if the Rave99 adapter card will still work in a normal TI-99/4A + PEB configuration after doing the changes?

 

I cleaned up the file for Wordpad, but need to study it. I noticed sometimes I have to re-seat the Speech card in the box if

it is not working (and I also see scrambled characters in the GPL startup page once in a while, not sure if it is related).

Now I have the Geneve 9640 in a stable mode (after 1.5 years) and happy with MDOS 7.30 on it

 

GENEVEBC-Rave99SpeechCardModForGeneve9640.TXT

 

Rave99 card in action in a normal TI-99/4A system setup:

 

 

 

[globeron]

 

Moving the MDOS 7.3 and GPL versions to this forum as suggested.

 

(here is the GPL 6.50 version of GPL I am using to compare - DSKA0001_Myarcboot.dsk

)

 

 

I saw some differences in GPL for both MDOS 7.30   GPL and MYGPL

use lowercase characters. Parsec does not display the full character. 

 

Press tire....to begin.

 

Also GPL shows 2x meteroites on the right top corner when crashing, but MYGPL and GPL650 do not.

 

Furthermore Ships, LIFT, Top, arrow are displayed in blue colour.  Gpl650 shows White.

 

For pictures and reply see here:

 

 

 

I had a chance to load GPL 7.30 with a PARSEC cart dump from my Geneve folder; 'tire' and 'begin' are wrong and that big "T" stands out.   My copy of GPL 5.00 exhibits the same patterns and colors.  I found an old GPL version 1.04 that did the same thing and another 1.04 that shows the uppercase lower character set but the ships, lift, top and fuel, and arrow are blue.  When I crash, I get 1-2 ships or asteroids.  Speed 5 is WAY too fast. 

 

Please post your various versions in the 7.30 thread and I'll compare to my files as time permits. I don't know that I ever played Parsec on the Geneve - there may have been good/bad cart dumps.  Still conjecture but I wanted to at least let you know it's not your hardware.

 

 

 

 

 

[globeron]

6 hours ago, 9640News said:

As far as I know, all DSKx devices from MDOS mode using the REMAP command are available as the same device number when in GPL mode AS LONG AS YOU ARE NOT USING ROMPAGE MODE!!!!

 

If you partition a Horizon Ramdisk wtih a HD partition, then it maps as a SCSx. devicename and you use the SCSMAP command, not the REMAP command.  And, as long as you do not use ROMPAGE mode in GPL, it too is available in GPL mode.

 

Beery

 

SCSMAP 48

ASSIGN F=SCS4:

 

(I tried also REMAP 3N (for Horizon 16 bit) and just in case REMAP 3F (for Horizon 8 bit), but my card indicates 16-bit in GENCFG.

When doing a dir DSK3 in MDOS command prompt it only shows the RAM-DSK  (not the HD)

 

when using GPL (the main screen to load modules, etc.)

I can use  SCS4. to load programs from the RAM-HD, that works.

 

(then I tried with F5 w/ROMPAGE and also the normal way)

 

but once in Extended Basic or EA,  I cannot load files from SCS4.   

 

* (e.g. using device   OLD SCS4.filename    or OLD SCS4.directory.filename)

* or use EA option 3 or 5 to   SCS4.filename

 

I think that XB and EA only allow DSKx access?    (sometimes max. to 3), that's why I want to

map RAM-HD = SCS4 to a DSK3 device 

(as I have A: / DSK1. for my Gotek drive and B: / DSK2. for my 3.5 floppy drive   and E: / DSK6. for RAM-DSK)

 

[+InsaneMultitasker]

RAMDSK and RAMHD are two separate partitions.  One is a "disk" partition, the other is a "hard drive" partition; one is accessed with DSKx. and the other with SCSx.   Both are accessible in native MDOS mode command line and in GPL.  Neither device is available in ROMPAGE mode.  (Rompage is rarely needed, so this should be a minor issue if at all to most people).

 

[+mizapf]

Just to clarify, the "tire" is just "fire" with the upper part of the character clipped. I noticed that problem with my own GPL mod for true lowercase characters long ago, shortly after getting the Geneve. It seems that Parsec is one of the few examples where the small capitals make sense.

[globeron]

5 hours ago, mizapf said:

Just to clarify, the "tire" is just "fire" with the upper part of the character clipped. I noticed that problem with my own GPL mod for true lowercase characters long ago, shortly after getting the Geneve. It seems that Parsec is one of the few examples where the small capitals make sense.

They optimized the space.  Same upper part here is missing for the d and b.

 

Press reao or oack.

 

 

[globeron]

11 hours ago, InsaneMultitasker said:

RAMDSK and RAMHD are two separate partitions.  One is a "disk" partition, the other is a "hard drive" partition; one is accessed with DSKx. and the other with SCSx.   Both are accessible in native MDOS mode command line and in GPL.  Neither device is available in ROMPAGE mode.  (Rompage is rarely needed, so this should be a minor issue if at all to most people).

 

 

Not sure why it did not work before, but

I just tested it again and it is working now in both XB and EA to load from SCS4.filename or SCS4.directory.filename  and also in programs and DM2K.   

 

 

Problem2:

(But after a while copying some files i get bad destination errors when copying to the HRD, it happened to the RAM-HD  then i reformatted it completely and also it happened on RAM-DSK, maybe related to the disk controller?  Or memory problems maybe, is there a memory test program for HRD3000 on Geneve?)

 

 

 

[+9640News]

Use the program GDM2K instead of DM2K after you have used GenCFG and reformatted your drives.  The program GDM2K runs from MDOS mode.

 

Report back what happens with the file copying process.

 

You have not mentioned it, but do you have a TIPI in your system?  What about a Rave Speech adapter?  What is the size of your HRD?

 

You mentioned "disk controller" with respect to the issues.  The HRD has no disk controller.  The HRD has memory only, and is basically a memory mapped device.  The DSR with MDOS (SYSTEM/SYS) contains everything needed to map and use the HRD's.

 

Beery