Altirra 3.90 released

[+DjayBee]

13 minutes ago, phaeron said:

emulation for the Atari 815 disk drive.

What a great idea.

 

17 minutes ago, phaeron said:

this is hard for me to test as ATX doesn't support double density disks yet and there aren't really any copy protected double density disks anyway.

Non-support of DD in the ATX format is correct, but Atari Accountant is actually copy protected by a missing sector.

Unfortunately the existing dumps are sector copies only, but if @ijor adds DD support to ATX, we could create an image with active protection.

 

https://atariwiki.org/wiki/Wiki.jsp?page=The Atari Accountant Series#section-The+Atari+Accountant+Series-ATRImages

 

The original disks were loaned by Curt. Therefore we currently have no way to get these and create flux dumps.

[Mclaneinc]

Did the 815 ever get to Europe?

 

I remember seeing it in our POS stuff at Maplin but I never saw one in the flesh as far as I remember...I know I wanted one

 

(and thanks to the genius of Phaeron I now virtually have one..Amazing)

 

Edit: From looking around (I'm not that lazy) it seems they were very rare and made in small numbers so its very unlikely it made it out of the US....Shame, looked really nice..

Edited September 13, 2020 by Mclaneinc

[+Nezgar]

On 9/13/2020 at 2:25 AM, phaeron said:

the drive formats with a 16:1 interleave, slightly faster than US Doubler standard interleave.

I wonder if the 815 could read disks with 15:1 (XF551, Happy 1050, Percom) or 14:1 (1050 Turbo) standard speed formatted interleaves without blowing revs? I guess we can simulate this in emulation now!

 

One other interesting aspect of the 815 is that data portions of sectors are inverted compared to all other Atari drives... (In reality all other drives store sector data inverted, with the 815 being the only one that doesn't - a tradition started with a bug the 810) Working with the savetz/luckybuck team to restore Atari Accountant confirmed my theory that the disks were readable in a happy 1050, but the sector data had to be inverted in post processing.

 

This is further evidence that Percom never had their hands on an 815 as an example, otherwise they may have mirrored the 815's 16:1 interleave, and non-inverted sectors for DD operation for compatibility...

 

Good to hear all the ROM dumps you've found are actually the same. There was source code from Curt from years ago, or maybe those were incomplete too. I recall there were comments in those sources suggesting unimplemented future intent for 38400bps over SIO, and double sided operation. Maybe for the 816 or 817. Ah yes, here we go: https://atariage.com/forums/topic/78379-atari-815-controller-source/?do=findComment&comment=4122495

 

Excerpt:

INMODE = $01DC ;INTERNAL MODE REGISTER
;
; BIT DEFINITIONS FOR INMODE:
;
; 7 - 19.2/38.4 KBAUD SERIAL DATA RATE (19.2 KBAUD = 1)
; 6 - DRIVE SELECT (TOP DRIVE = 1, BOTTOM DRIVE = 0)
; 5 - SIDE SELECT (FOR DUAL HEADED DRIVES, SIDE0=0, SIDE1=1)

[Mclaneinc]

Phaeron (or anyone that knows the answer), went to play with the Rapidus as I'd seen a couple of demo's on KMK's rapidus site.Now I am probably doing something wrong but I thought I'd ask.

 

When I enable the rapidus the top bar shows it as a +816 and Rapidus but when I launch the stars exe I get the bootstrap screen and then it says its not a 65C816 cpu?

 

If I hold inverse down it says its a 65C816..

 

I must admit I've not used Rapidus in a while so I may be getting it wrong..

[drac030]

You may need to set Rapidus OS as OS, as these programs mostly run in the native mode, thus extended interrupt services are required. Otherwise I am clueless.

 

I must admit that I have never tried to configure Altirra in Rapidus mode, so I do not know how this works. The generic emulation (CPU 65C816/21 MHz + 4 MB high memory + Rapidus OS) should be enough to run most programs, so I use such a setup whenever I need to check how the code behaves in slightly different environment.

[flashjazzcat]

Using test11 and mounting a CAR file (in this case, a 64K Williams cartridge) seems to result in the 16 byte file header appearing in the cartridge memory space:

[phaeron]

9 hours ago, Mclaneinc said:

Phaeron (or anyone that knows the answer), went to play with the Rapidus as I'd seen a couple of demo's on KMK's rapidus site.Now I am probably doing something wrong but I thought I'd ask.

 

When I enable the rapidus the top bar shows it as a +816 and Rapidus but when I launch the stars exe I get the bootstrap screen and then it says its not a 65C816 cpu?

 

If I hold inverse down it says its a 65C816..

 

I must admit I've not used Rapidus in a while so I may be getting it wrong..

Check or reflash the '816 OS on the emulated Rapidus -- this program not only needs a 65C816 but also an OS's compatible enough with a recent version of the 65C816 OS. AltirraOS/816, for instance, doesn't seem to work (haven't looked into why).

 

6 hours ago, flashjazzcat said:

Using test11 and mounting a CAR file (in this case, a 64K Williams cartridge) seems to result in the 16 byte file header appearing in the cartridge memory space:

Check the cart checksum or try launching with /nocartchecksum. If the checksum fails the emulator will parse the file as a raw binary instead of CAR format.

[phaeron]

http://www.virtualdub.org/beta/Altirra-4.00-test15.zip

http://www.virtualdub.org/beta/Altirra-4.00-test15-src.zip

• Fixes an issue with Rapidus emulation where an unclean CPU switch would occur from 65C816 to 6502 mode.
• 815 emulation now supports writing and formatting. Note that attempting to format a format-protected disk (VRWSafe mode) will end up going through the entire format, as the emulator has no way to know that the 815 is trying to format the disk until it's too late to stop it (though it will block the writes).
• Fixed an 815 bug with sector corruption across the index mark.
• Fixed an 815 bug with the drive indicator being left on for drive 2.
• 815 drive ID configuration now works.

 

23 hours ago, Nezgar said:

I wonder if the 815 could read disks with 15:1 (XF551, Happy 1050, Percom) or 14:1 (1050 Turbo) standard speed formatted interleaves without blowing revs? I guess we can simulate this in emulation now!

I don't think so. Altirra formats double-density disks as 15:1 by default when loading from ATR and the 815 is not doing that well with some game loaders. It has a fast controller but spends a ton of time manually computing data frame CRC-16s, 16.5ms, which is done for free on all other disk drives. To put it in perspective, a rotation at 288 RPM is 208ms, so this is 8% of a rotation, or about a sector and a half. For comparison, the 1050 is faster than the 810 by about 2ms due to interleaved SIO checksumming and that's already big enough to make the difference with some loaders.

 

Problem is, doing it the conventionally fast way requires 512 bytes of table data -- 16-bit feedback values for all possible feedback bytes to be specific. There isn't that much available space in the ROM and freeing it up would have been a lot of work, and even then the CRC-16 computation probably would still take longer than it takes the 810 to do the SIO checksum. There's a reason why modern CPUs have instructions to do GF(2) arithmetic, because emulating it with conventional operations sucks.

 

23 hours ago, Nezgar said:

One other interesting aspect of the 815 is that data portions of sectors are inverted compared to all other Atari drives... (In reality all other drives store sector data inverted, with the 815 being the only one that doesn't - a tradition started with a bug the 810) Working with the savetz/luckybuck team to restore Atari Accountant confirmed my theory that the disks were readable in a happy 1050, but the sector data had to be inverted in post processing.

Yeah, I'm basically ignoring this since the backing store is decoded data, so you can freely exchange disk images with the other drive types in ways that wouldn't work with a real 815. However, I don't think anyone has use for ATRs that have inverted data. The low-level sector format is textbook IBM disk format, so it's not surprising that the Happy drive was able to read it.

 

23 hours ago, Nezgar said:

This is further evidence that Percom never had their hands on an 815 as an example, otherwise they may have mirrored the 815's 16:1 interleave, and non-inverted sectors for DD operation for compatibility...

Yup, I'm beginning to suspect that the 815 was unknown to almost everyone and that it's DOS that was the conduit for the conventions like drive status bit 5 and the three boot sector convention. Even if no one else had seen a double-density drive, everyone could see the code in the DOS 2.0S boot sector to handle a double density boot. AFAIK Atari didn't officially support this again in drive hardware until the XF551 and that was much later.

 

23 hours ago, Nezgar said:

Good to hear all the ROM dumps you've found are actually the same. There was source code from Curt from years ago, or maybe those were incomplete too. I recall there were comments in those sources suggesting unimplemented future intent for 38400bps over SIO, and double sided operation. Maybe for the 816 or 817. Ah yes, here we go: https://atariage.com/forums/topic/78379-atari-815-controller-source/?do=findComment&comment=4122495

As far as I can tell that source is accurate to the images that we have, but it's not very readable and is also in a weird syntax that modern assemblers won't take, which is partly why I opted to disassemble it instead. There are some mistakes in the listing, like the second ROM half being documented at $7000-77FF when it was actually assembled at $1000-17FF.

 

Pretty much none of the interesting features you see in that listing are in the controller ROM, they're all dependent upon the expansion ROM that doesn't exist and would require ROM 1 to be replaced anyway, and in some cases a bunch of missing parts to be added to the board. No high speed, no 80 track, no double sided.

 

[drac030]

7 hours ago, phaeron said:

an OS's compatible enough with a recent version of the 65C816 OS

I think the required function in question may be the high memory allocator. But (according to the changelog) I have added it 14 years ago, so I am not sure if it is so recent

[flashjazzcat]

8 hours ago, phaeron said:

Check the cart checksum or try launching with /nocartchecksum. If the checksum fails the emulator will parse the file as a raw binary instead of CAR format.

I'm not sure whether the checksum is right or wrong or how it is calculated, but when starting Altirra with the /nocartchecksum switch, behaviour is no different: the CAR header still appears at $A000.

 

ALLEY CAT (WILLIAMS).CAR

[+Nezgar]

6 hours ago, phaeron said:

I don't think so. Altirra formats double-density disks as 15:1 by default when loading from ATR and the 815 is not doing that well with some game loaders.

Interesting - thanks for this observation, hadn't got to it myself yet!

 

6 hours ago, phaeron said:

I'm basically ignoring this since the backing store is decoded data, so you can freely exchange disk images with the other drive types in ways that wouldn't work with a real 815. However, I don't think anyone has use for ATRs that have inverted data.

 

I fully support this stance... No need to replicate the 'incompatibility' in emulation... that would be truly annoying.

6 hours ago, phaeron said:

conventions like drive status bit 5

Wondering what status bit 5 was, I couldn't find it mentioned in the latest release of the Altirra HW reference manual in my possession (2019-12-30) - but found it elsewhere "Sector size (0=$80 1=$100)" : https://www.atarimax.com/jindroush.atari.org/asio.html

 

And yes you are correct, the 815 and XF551 were the only Atari made drives that supported true double density. But The XF551 was made by a completely different team (person?) so the 815 would have not been a design influence, rather the Percom standard that every other 3rd party drive or enhancement was already using.

 

6 hours ago, phaeron said:

I opted to disassemble it instead.

Do you have a link to where this is posted (if it was posted) handy? I'm out of search-fu this morning.

[phaeron]

7 hours ago, flashjazzcat said:

I'm not sure whether the checksum is right or wrong or how it is calculated, but when starting Altirra with the /nocartchecksum switch, behaviour is no different: the CAR header still appears at $A000.

 

ALLEY CAT (WILLIAMS).CAR 64.02 kB · 5 downloads

You have to load the image on the command line for the switch to work. And indeed, the checksum is wrong:

 

Python 3.8.2 (tags/v3.8.2:7b3ab59, Feb 25 2020, 22:45:29) [MSC v.1916 32 bit (Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import struct
>>> dat = open("alley cat (williams).car", "rb").read()
>>> print((sum(dat[16:]), struct.unpack('>I', dat[8:12])[0]))
(3169074, 1556771)

 

3 hours ago, Nezgar said:

Do you have a link to where this is posted (if it was posted) handy? I'm out of search-fu this morning.

No, I have not completed or posted it yet.

 

[FULS]

Alley Cat (Williams).bin

Alley Cat (Williams).car

 

Not sure if this is what your after, but just in case here are 2 correct images of Alley Cat.

 

 

[avanze]

32 minutes ago, FULS said:

Not sure if this is what your after, but just in case here are 2 correct images of Alley Cat.

Alley Cat was released on cartridge?

[flashjazzcat]

57 minutes ago, FULS said:

Alley Cat (Williams).bin 64 kB · 3 downloads

Alley Cat (Williams).car 64.02 kB · 4 downloads

 

Not sure if this is what your after, but just in case here are 2 correct images of Alley Cat.

Many thanks - that one actually mounts properly.

[lemiel]

About that CAR file loading:

 

1. If checksum is wrong and size is bigger with those 16 bytes could be that image loaded with that 16 bytes "offset".

 

2. Is there any possibility to alert user about that wrong checksum of loaded file and loading as raw binarny?

[flashjazzcat]

5 minutes ago, lemiel said:

1. If checksum is wrong and size is bigger with those 16 bytes could be that image loaded with that 16 bytes "offset".

That's certainly the approach I'm taking in my loader if the file size suggests there's a sixteen byte header. Not that I bother to verify the checksum, but if I did and it didn't match, I would issue a message to that effect.

[scotty]

Have a quick question....   Woke up in the middle of the night, and could not go back to sleep, so I did what any normal Atari loving geek would do, and fired up Altirra.   Decided I wanted to try telneting to a BBS.    loaded the 850 emulator and went to terminal mode, did the ATDI command along with the address...  blah blah blah...  Long story short, it worked.

 

Problem is I have a blue message across the bottom of the screen telling me I am connected to the BBS, and it is in the way of the bottom row of text on the screen.  Is there any way to turn it off or move it?   Looked in modem settings and could not find it.  Thanks in advance.

 

[phaeron]

14 hours ago, lemiel said:

About that CAR file loading:

 

1. If checksum is wrong and size is bigger with those 16 bytes could be that image loaded with that 16 bytes "offset".

 

2. Is there any possibility to alert user about that wrong checksum of loaded file and loading as raw binarny?

There are some cartridge images with weird sizes, and the checksum is part of how the emulator detects a CAR image since people of frequently use the wrong extensions. I'm not terribly fond of encouraging file format pollution by allowing CAR files with bad checksums, but I'd have to check how often it actually gets validated by various programs.

 

12 hours ago, scotty said:

Have a quick question....   Woke up in the middle of the night, and could not go back to sleep, so I did what any normal Atari loving geek would do, and fired up Altirra.   Decided I wanted to try telneting to a BBS.    loaded the 850 emulator and went to terminal mode, did the ATDI command along with the address...  blah blah blah...  Long story short, it worked.

 

Problem is I have a blue message across the bottom of the screen telling me I am connected to the BBS, and it is in the way of the bottom row of text on the screen.  Is there any way to turn it off or move it?   Looked in modem settings and could not find it.  Thanks in advance.

You can't hide just that indicator, but there are options both to hide all indicators and to expand the overscan region to accommodate it (in view > overscan).

[scotty]

2 hours ago, phaeron said:

There are some cartridge images with weird sizes, and the checksum is part of how the emulator detects a CAR image since people of frequently use the wrong extensions. I'm not terribly fond of encouraging file format pollution by allowing CAR files with bad checksums, but I'd have to check how often it actually gets validated by various programs.

 

You can't hide just that indicator, but there are options both to hide all indicators and to expand the overscan region to accommodate it (in view > overscan).

Thank you sir

 

[Atari Nut]

I have been having an issue with save states in version 3.90.  I was trying to save Miner 2049er Station 5.  Two of the states produced garbled graphics when loaded and the third just started the game from Station 1.  Has anyone else had similar issues?  These were standard saves, not quick saves.  Where are quick saves saved?

[Mclaneinc]

Memory IIRC, hence they are quick saves, ie to use in the current gaming session.

[Shannon]

Again.  Thanks for your continuing support of our favorite 8-bit computer.

 

I have a question.  I'm looking at OS sets and I'd like to know the difference between OS-A NTSC and OS-A PAL.  Is there a doc out there that breaks down the diff between the many versions that have been discovered over the years?

 

Thank you

[+Nezgar]

1 hour ago, Shannon said:

the difference between OS-A NTSC and OS-A PAL

The timers that account for the difference between 50/60hz are modified such that key click rate, and cassette I/O will be the same. You will get timing mismatches if you run a PAL OS on an NTSC machine, and versa. XL/XE type OS's detect the hardware and adjust appropriately with the same ROM.

[Shannon]

6 hours ago, Nezgar said:

The timers that account for the difference between 50/60hz are modified such that key click rate, and cassette I/O will be the same. You will get timing mismatches if you run a PAL OS on an NTSC machine, and versa. XL/XE type OS's detect the hardware and adjust appropriately with the same ROM.

 

ok.  Thanks alot for the answer.  While doing some updating I realized that the OS-A AND OS-B ROM sets that I had were PAL ( one wasn't "technically" a real BIOS ).  So I've been focusing on making sure I have the right sets for what I need.