Jump to content
IGNORED

Altirra 2.80 released


phaeron

Recommended Posts

altirra full bios pack !

I am using 2.9 Test 10. I extracted all files into the altirra bios folder, selected scan, and pointed it to that folder. I got a message saying 33 recognized, 33 present. But for SIDE, SIDE2, etc. the are no entries underneath. Do I have to manually add them?

Link to comment
Share on other sites

altirra full bios pack !

 

Too cool for school! But still needs sum educashun.. These dumps are identical and generate the same checksums:

 

OS Rev B (1981) (Atari) (NTSC) (400-800) V1.rom

OS Rev B (1981) (Atari) (NTSC) (400-800) V2.rom

3e28a1fe

 

Atari 1050 vB.rom

1050-revK.rom

3abe7ef4

 

Atari 1050 vA.rom

1050-revL.rom

fb4b8757

Edited by Keatah
Link to comment
Share on other sites

Avery, xf551 and indus gt - also will be added?

 

Maybe, eventually. Those two are tougher because they use non-6502 derived CPUs -- 8048 and Z80, to be specific. Altirra supports 65C02 and 65C816, but they're still in the 6502 family.

 

I have noticed that Altirra auto recognises a patched OSB rom.

 

What is this file "patched" to do, and why would you auto verify a non standard rom?

 

k1w1

 

That entry is for the atariosb.rom file from Xformer. It's been patched to initialize the PIA differently, to add a hard stop on the memory test at 52K, and it assumes that memory is cleared to $00 on power-up (it's not on real hardware). Ordinarily I don't put patched firmwares in the autodetection list, but I made an exception for that one since it's so ridiculously common that most people don't even realize their OS-B is patched.

Link to comment
Share on other sites

That entry is for the atariosb.rom file from Xformer. It's been patched to initialize the PIA differently, to add a hard stop on the memory test at 52K, and it assumes that memory is cleared to $00 on power-up (it's not on real hardware). Ordinarily I don't put patched firmwares in the autodetection list, but I made an exception for that one since it's so ridiculously common that most people don't even realize their OS-B is patched.

 

Thanks for the explanation Avery and thanks for your continued additions to Altirra. As if it was not already one of the most comprehensive, accurate and complete emulators around for any system you haven't rested on your laurels and continue to improve and tweak for the benefit of this community.

Link to comment
Share on other sites

Update:

http://www.virtualdub.org/beta/Altirra-2.90-test11.zip

http://www.virtualdub.org/beta/Altirra-2.90-test11-src.zip

 

Adds support for the 1050 Duplicator. It's basically the same memory map as the TOMS 1050, and it has the same abnormally slow byte transfer rate, which leads me to believe the two may be related somehow. There are a couple of caveats, though. First, if you have a firmware image that is 8199 bytes long, you'll need to trim the cruft off the ends, specifically a bogus 6-byte program header at the start and an extra byte at the end. Second, the 1050 Duplicator firmware takes an abysmally long time to recognize an MFM disk on power-up, since it does three slow seeks at start and then wastes a full rev trying to scan for FM followed by another full rev to scan for MFM. I don't know if there's an issue in the emulation that's triggering this, but in any case it's long enough for the OS boot to time out with an enhanced or double density disk. The workaround for now is to enable Ultimate1MB and use its soft-reset (Help+Reset, or F6+F5) to reset the computer without resetting the drive. Or you could just use a better drive....

 

Other misc changes: fixed CRC computation for FDC Read Address command on MFM disks, and added .crc command to the debugger.

  • Like 3
Link to comment
Share on other sites

Second, the 1050 Duplicator firmware takes an abysmally long time to recognize an MFM disk on power-up, since it does three slow seeks at start and then wastes a full rev trying to scan for FM followed by another full rev to scan for MFM. I don't know if there's an issue in the emulation that's triggering this,

The Duplicator does have a few issues with MFM disks and density detection. One of them, but not the only one, is that is uses a format for double density that is not fully compatible with the, then, de facto Atari standard:

 

http://atariage.com/forums/topic/102644-1050-us-duplicator-identification-needed/?do=findComment&comment=1252357

 

 

 

 

Link to comment
Share on other sites

You probably have it and don't realise it, its in the pack from here

 

http://www.realdos.net/MegaDownload.html

 

Since it needed editing I've done that and here it is..

 

Also remember what Avery said, its timing out on MFM disks, just use 90K disks to test it...And the (1) in the file name can be removed, its simply from downloading it twice..And lastly, do a show all files to add it as firmware..

DTIREV5(1).zip

Edited by Mclaneinc
  • Like 2
Link to comment
Share on other sites

http://www.realdos.net/US%20Doubler.html because example link was not mentioned before when ijor wrote about adding US Doubler too.

Thanks for Tiger.

About Duplicator and TOMS similarities: Poland was on another side of Iron Curtine but many people, if they had a possibility, were visiting USA or Canada for better life - mostly for money - salaries and exchange rate was not comparable. And people were sending or bringing to Poland Ataris. My classmate got 800, 800XL and some Rana drive send by his dad, but they emigrated few years later to Canada. So probably somebody near TOMSes had Duplicator and they took it, repair DD and maybe something else, add IBM 180kB SS format, Turbo 1050 (I am not sure if it is there) and who knows what more. Maybe this IBM format was even inspired by this bad Duplicator behaviour in DD.

But this is only some kind of conspiracy theory. People which did this aren't on Atari scene now or didn't acknowledged that they did it.

Edited by lemiel
Link to comment
Share on other sites

These things always happen although Happy, Spartan and ICD would probably not been so happy about it in the day, but in some way it improved upon Happy with little additions but there were also mistakes with some of the knock offs, that's the way it goes.

 

First time I saw a happy was just before I worked for Maplin, there was a guy who turned up there every Saturday with his silver Atari jacket, he unpacked his Happy and copied software for the customers, the staff knew and turned a blind eye in exchange for copies of the latest stuff around, there was also a similar guy who did this at Silica Shop in Kent, he would just wander up to people and say 'you want that cheaper?' and did the deed but not in the shop. These early adopters of Happy's made a small fortune, by the time I worked for Maplin this practice was ended at our branch, common sense prevailed and as an Atari dealer it was amazing the branch got away with the allowance of Kevin to sit there and copy with Atari UK being very close and whispers were going back to them.

 

The other guy (Reg, an ex bank robber (seriously)) was also booted out of the Silica shop when they found out but he had a good run...

 

I acquired a 'Lazer' drive late on, another Happy clone, would be nice for old times sake to see that dumped..Sadly I lost all my gear...

Edited by Mclaneinc
  • Like 1
Link to comment
Share on other sites

Update:

http://www.virtualdub.org/beta/Altirra-2.90-test12.zip

http://www.virtualdub.org/beta/Altirra-2.90-test12-src.zip

  • Reimplemented SIO transmissions from full drive to POKEY. This eliminates a byte delay that was causing Happy warp mode to fail, since it has a very fast speed switch between ACK and Complete.
  • Drive emulation speed is now adjusted for NTSC/PAL. This is unfortunately the result of investigating high-speed write issues with the Speedy 1050, which turned out to be due to a marginal read loop on the drive side. Speedy 1050 high speed mode operates at a POKEY divisor of 9, or 32 computer cycles per bit. Reads are fine, but data frame writes are tight on the drive because the read loop is 180 cycles at 1MHz. In PAL, this just barely works because 320 cycles @ 1.77MHz comes out to 180.8 drive cycles, but in NTSC 320 cycles @ 1.79MHz = 178.7 drive cycles. This was causing the drive to lose a bit halfway through the data frame in NTSC. :(
  • Disk change is now emulated, including the write protect sensor and the not ready bit on the 1050. This is necessary for the 1050 to recheck density and for enhanced drives to flush their track read buffer. As a result, you will now hear the motor spin up and possibly a seek when switching disks. The not ready status bit is also now continuously updated after type II/III commands, as this is required by the 1050 (and yet another omission in the FDC docs).
  • Fixed FDC transfer timing being too fast for single density in 1050 drives.
  • Read/write operations now fail on half tracks.
  • Formatting is now supported for MFM formats (enhanced/double density).
  • Tweaked the FDC to work around some firmwares locking up when trying to format a disk with formatting blocked (VRWSafe mode) because they cannot handle a write protect error on the Write Track command. 810 and 1050 now fail the format command quickly; some enhanced drive firmwares will still attempt the format, and for protected disks on those drives you will need to force the disk mode to full read-only (R/O).
  • Fixed transmission errors with full drive emulation when SIO burst mode is enabled for disk drives; this is now ignored by the full drive emulator since it is not supported.
  • Fixed a bug with the standard drive emulator not getting re-enabled when removing a full disk drive.
  • The swap/rotate commands now work for full disk drives.
  • Added .fdc and .riot commands in the debugger.

As a side note, you may need to enable accurate disk timing for enhanced drives to enable track buffering, like the Speedy 1050. This is probably because the drive thinks there are way too many sectors per track otherwise.

  • Like 3
Link to comment
Share on other sites

Small issue here, if I set D1: as a 1050 happy (under latest beta above) it happily (no pun intended) boots a disk but if I try and boot a different disk then it times out without booting, if I then try and boot a disk it works but a try at booting a different disk thereafter returns to the time out. One little odd thing, if I try and reboot the same disk it works every time, like its stuck in a big buffer?

 

Hopefully repeatable at your end...

 

Also tried accurate timing..same issue..

Edited by Mclaneinc
Link to comment
Share on other sites

phaeron, would it be possible

 

- either to expose the real disk emulation via an API to external programs like RespeQt?

- or to make a library from it which could be linked to disk emulators?

 

Then it would be possible to create ATX images using a Happy drive and a PC - without Kryflux or ijor's VAPI imaging tool.

Edited by DjayBee
  • Like 2
Link to comment
Share on other sites

Just checked I had the right firmware for Happy 1050 and noticed it wasn't the one pointed out by you Avery, so went and got that and the same issue I mentioned a couple of posts above where it pretty much always won't boot another image directly after one has been loaded but will if you try a 2nd time remains. The only difference is that where it was booting the exact same disk without the issue it now does not...Just times out...

 

Stranger...This only happens if you load / boot a disk via the file menu, if you double click an associated file with a reusable Altirra window it boots as many as you like one after the other...

Edited by Mclaneinc
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...