Atari 1050 Happy Enhancement ROM Question

[Binarygeek]

Hello all

 

Has anybody out here ever heard of the 1050 Happy ROM having a revision 1 and revision 2? I have not, but I could be wrong. If so, what does the latter revision address? Somebody told me that it targeted the US Emulator mode. I said I would look in to it, and ran straight to here.

 

Regards,

Rick

[+Nezgar]

There is specific mention of this in the Happy 1050 manual. You can tell what version you have, diagnostic test will show 'PASS' for v1 and 'Pass' for v2.

 

The 'ultraspeed emulation' is a bit of a misnomer... it will enable fast buffered reads, and non-buffered writes, but I wish they almost didn't add that feature because writes to single density disks in this mode will corrupt byte 3 of every sector written.

 

Disk formatting will also still result in the normal 9 sector interleave, and not the USDoubler interleave.

 

Full USD Emulation, with USD skew format support is only posible on a happy drive by using Steve Cardens HAPPY.COM utility included with RealDOS. It literally uploads the USD rom to the happy RAM and executes it. It will be a true USD until powered off.

[Binarygeek]

There is specific mention of this in the Happy 1050 manual. You can tell what version you have, diagnostic test will show 'PASS' for v1 and 'Pass' for v2.

 

Well I'll be damned. You learn something every day. Thanks so much for that. I just looked at the installation PDF...and there it is, just like you said. OUCH!

Edited July 1, 2017 by Binarygeek

[+kheller2]

The 'ultraspeed emulation' is a bit of a misnomer... it will enable fast buffered reads, and non-buffered writes, but I wish they almost didn't add that feature because writes to single density disks in this mode will corrupt byte 3 of every sector written.

 

Wait, what?

[+Nezgar]

Wait, what?

Yep. Boot up with SpartaDOS 3 and do some writes to a single density disk

 

I guess I never ran across this back in the day because I primarily used SpartaDOS X, which the ICD versions include 'INDUS.SYS' in the default config.sys which reprograms happy drives properly to highspeed with fast writes which avoids the issue.

 

The current SDX 4.48 I'm using doesn't include INDUS.SYS in the default config.sys so it's also easy to reproduce if I forget to manually load it.

 

I guess back in the day I never wrote to disks with SpartaDOS 3 because I would only drop out of SDX to run BBS Express 5, and the custom SpartaDOS 3.3 for the BBS didn't do high speed SIO at all I think, which saved a few bytes of RAM. (perfectly fine when you're running purely from MIO hard drive and RAM disk) Also, I would have been primarily working with double density disks for backups from the hard drive, which also would have avoided the issue ...

 

I noticed lately there's also a vague reference to this corruption bug in the happy 1050 manual itself, and the MyCopyR! Sector copier release notes mention one revision that will now always enable fast writes rather than make it selectable to workaround the bug in happy drives.

 

I'll have to dig those up and quote them here later

Edited July 2, 2017 by Nezgar

[ijor]

The problem is that high speed (USD ultra speed emulation) can cause corruption if buffered writes are not enabled. The issue was more critical with the newer Happy rom because it enabled USD emulation by default.

Full USD Emulation, with USD skew format support is only posible on a happy drive by using Steve Cardens HAPPY.COM utility included with RealDOS. It literally uploads the USD rom to the happy RAM and executes it. It will be a true USD until powered off.

The Happy ROM can easily be "extended" with extra commands. It should be quite simple to add support for the USD 'f' skew format command.

[+Nezgar]

Ok, true. I guess I meant 'currently' the only way haha

[gargoyle]

is there a revision 7 ROM out in the wild and do anybody have a link?

[ijor]

is there a revision 7 ROM out in the wild and do anybody have a link?

 

There is no such thing as "revision 7 ROM" for the Happy 1050. The only (official, at least) ROMS are rev 1 and 2. They should be posted somewhere at the Altirra thread that integrated full Happy emulation.

[gargoyle]

 

There is no such thing as "revision 7 ROM" for the Happy 1050. The only (official, at least) ROMS are rev 1 and 2. They should be posted somewhere at the Altirra thread that integrated full Happy emulation

 

Warp Speed Software Revision 7 User Manual mentions rev 7 ROM for 1050:

 

[+Nezgar]

Man that paragraph is hard to follow... implies the two roms are named Rev 2 (the older one) and Rev 7 (the newer one). And last sentence 'not fully compatible' is the implied reference to the corruption, to not use it without write buffering.

 

Edit: reading it again, 7 is the older original ROM, and had supposedly a slower 'warp speed' SIO speed compared to USD ultraspeed. 2 is newer, and defaulted to the faster SIO speed (so the enable USD Emulation menu option would essentially have no effect) but manual enable of fast writes would still be necessary for both. (to be 'fully compatible' as per happy, read: to not corrupt byte 3 of single density sector writes)

Edited July 2, 2017 by Nezgar

[+kheller2]

Wow. I think I'll stick with the 1050 Duplicator format bug (DD first three sectors). The Happy is a nice board, but I was smitten with a real USD and Duplicator pair of 1050s in my youth; everything else just seems cumbersome. (There are a few enhacments I haven't gotten to spend time with yet.)

[ijor]

I'm not sure why that part of the manual names that ROM as "revision 7". I agree with Nezgar that it is referring to the older original ROM. I knew it as rev 1.

 

Anyway regardless the name, rev 1 or rev 7, it is the older original ROM and a link should be in the Altirra thread.

[toddtmw]

I'm not sure why that part of the manual names that ROM as "revision 7". I agree with Nezgar that it is referring to the older original ROM. I knew it as rev 1.

 

Anyway regardless the name, rev 1 or rev 7, it is the older original ROM and a link should be in the Altirra thread.

Probably an OCR failure.

[HiassofT]

Probably an OCR failure.

You nailed it! Just checked the ugly, non-OCRed version and there it reads rev 1:

 

 

so long,

 

Hias

Edited July 2, 2017 by HiassofT

[gargoyle]

Damn OCR , wonder what else is wrong with that user manual... But I guess there is a rev 7 ROM after all, although it looks like it is for the 810: http://atariage.com/forums/topic/257578-happy-810-resources/?p=3692606

Edited July 2, 2017 by gargoyle

[+Nezgar]

Now I'm curious to see a happy 1050 V1 in action to see if it really uses a slower SIO speed natively... that version is probably pretty rare. All my happy boards have soldered on roms or eproms, so not an easy thing to swap.

 

I've also not seen a happy 810 in action. The lower SIO speed should exhibit there too at least prior to V7. Likely in the 38400bps range. It may be the same speed I hear used in the happy backup utility.

Edited July 2, 2017 by Nezgar

[AtariGeezer]

The V1 ROM s posted on the Smirk-1050 thread: http://atariage.com/forums/topic/128791-atari-1050-smirk-happy-clone/page-2?do=findComment&comment=3322954

[HiassofT]

The V1 ROM s posted on the Smirk-1050 thread: http://atariage.com/forums/topic/128791-atari-1050-smirk-happy-clone/page-2?do=findComment&comment=3322954

Thanks a lot for the ROM dump! I must have missed that back then when you posted it.

 

Never saw a rev1 happy in action before, so I flashed it to my MegaSpeedy, ran the diagnostics and saw the large ASS for the first time (pun intended)

 

Also quickly checked with my highspeed SIO code, as expected only happy warp speed (38kbps) is supported on rev1.

 

so long,

 

Hias

[+Nezgar]

Good stuff Hias! Can you check:

 

Can v1 still be bumped up to 56k using both the 'enable USD emulation' and 'enable fast writes' menu options as mentioned in the manual?

 

If so, will the SDX INDUS.SYS perform both those settings as well?

 

Lastly, does v1 still corrupt single density writes if USD Emulation is enabled, but fast writes are left disabled?

Edited July 3, 2017 by Nezgar

[HiassofT]

Enabling USD emulation via drive options bumps the speed to 56k, and after doing this I couldn't reproduce the write errors, even when I didn't enable fast writes.

 

I tested with the Turbo Freezer, perpared a special version for this test (usually the highspeed code enables fast writes if it detects a happy - I disabled that part of a code) and cross-checked with the rev2 happy code. On the rev2 I got the corrupted 3rd byte, but on rev1 with USD emulation I didn't.

 

I then dug further, traced the SIO commands from the "enable USD emulation" option and saw that the last command was $48 with AUX $0020 - which is "enable fast write".

 

So it looks like they knew about the issue, fixed the software and added a note to the manual, but maybe they discovered this too late and couldn't fix the ROM. But that's just a wild guess.

 

I also did a quick test with SDX 4.48, default config.sys from car contains "DEVICE INDUS 4", but with a cold-started rev1 ROM it doesn't enable any highspeed functionality - the happy rev1 drive was accessed in standard speed. Looks like indus.sys only supports ultra speed but not happy warp speed.

 

Then I enabled USD emulation, booted SDX again, and it used ultra speed mode. In the SIO log I also saw that it issued the $48/$0020 "enable fast writes" command after the $3f (get ultra speed divisor) command.

 

so long,

 

Hias

[+Nezgar]

Great investigation Hias, very interesting! So purely educational at this point as it would be slower, but would there be any current way to use warp speed mode in spartados without first enabling USD emulation in v1?

 

That would be an annoying 2 step process to get ultraspeed with Sparta, or most high-speed SIO software actually with a rev 1 rom.

 

I wonder what degree of USD emulation existed in the happy 810 roms. Maybe nonexistant prior to rev 7. (warp speed only)

[HiassofT]

AFAIK the happy 810 only supports warp speed.

 

Concerning SDX: You'd have to prod the SDX devs to add support for the Happy warp speed protocol to their SIO driver. As it's almost identical to the XF551 protocol that should be rather easy to implement.

 

Or you could try to use the U1MB highspeed SIO PBI driver, that should support warp speed as well and would override the SDX SIO driver. Haven't tested this though, @flashjazzcat can probably tell you more about that.

 

so long,

 

Hias

[sup8pdct]

Wow. I think I'll stick with the 1050 Duplicator format bug (DD first three sectors). The Happy is a nice board, but I was smitten with a real USD and Duplicator pair of 1050s in my youth; everything else just seems cumbersome. (There are a few enhacments I haven't gotten to spend time with yet.)

sure it is a bug?. Digging through the roms of usd, indus etc, the 1st 3 sectors are 256 bytes long, the firmware just sends/receives 128 bytes and pads out the other 128 bytes to fill the sector.

 

James

[+Nezgar]

Problem is that the Duplicator physically formats sectors 1-3 as 128 Bytes, rather than 256 and truncating the extra 128, which breaks most other drives density detection.

 

Found the reference http://atariage.com/forums/topic/102644-1050-us-duplicator-identification-needed/?p=1252357

Sorry for not being clear. The behavior depends on the other firmware's drive, not in the Duplicator's firmware version. It is possible that the issue was fixed in some version, but I think I checked the last one and I didn't see the fix.

The problem is how the first track is formatted, more precisely the 3 first sectors. As you may know, the 3 first sectors of a DD disks are treated as if they were in SD. The sectors on a DD disks have 256 bytes instead of 128. But the 3 first sectors are transferred as 128 bytes. This is to allow booting from a computer OS that is expecting a SS disk.

The standard is to format all tracks identically, even the first one. That is, those 3 sectors are still formatted as 256 bytes. Only that when they are transferred to the computer in either direction, the transfer is for the first 128 bytes only.

But the Duplicator formats the first track in a different way. The 3 first sectors are physically formatted with 128 bytes. This will break other drives when trying to detect the density of the disk. Because density detection depends on the sector size to distinguish between enhanced and double density.

In the case of the USD, it will work correctly when the density detection reads a sector number higher than 3 (4-18); because those sectors are always 256 bytes. It will break the density detection if it happens to read one of the first 3 sectors. In the latter case the USD will "think" the disk is in medium/enhanced density.

Not like Atari published a standards document for drive makers at the time. Percom paved the DD path, I guess this would be a pretty easy oversight to make... Solution is to just format DD disks in other drives I guess.

Edited July 4, 2017 by Nezgar