Jump to content
IGNORED

Altirra 2.60 released


phaeron

Recommended Posts

Update:
http://www.virtualdub.org/beta/Altirra-2.70-test9.zip
http://www.virtualdub.org/beta/Altirra-2.70-test9-src.zip

First, I took another look at the ATBasic source and managed to free up about 150 bytes for some revisions. V1.40 is attached and has three changes:

  • Fixed a bug where FOR X + GOSUB + FOR X was acting incorrectly. In Atari BASIC, FOR statements will pop the runtime stack down to the previous invocation of FOR with the same variable, but not if there is a GOSUB in between. This actually broke a program called Escape From Epsilon.
  • USR(100000) now properly throws an error.
  • Basic XL's IF..ELSE..ENDIF is now supported. This took a lot more space than I expected, partly due to the need for a special case in the parser to handle ENDIF, and because of the need to parse past expressions to check for THEN keywords in nested IFs. No indenting during LISTing, though.

Hopefully I didn't break anything in the process.

In the emulator:

  • Partial fix for bug in ATOS where positioning the cursor out of bounds would cause infinite errors from E:, which is supposed to push the cursor back in bounds.
  • Fixed regression in H: where the NOTE/POINT commands stopped working, due to the new device framework not handling ICAX3 properly.
  • Data checksum errors during disk transfers now give a NAK instead of a device error, as the real 1050 does.
  • The debugger's break on expression (bx) command can now create tracepoints like bp, with -n.
  • Fixed crash in watch window when canceling edit.
  • Direct3D 11 display driver now supports DXGI 1.3 waitable vsync. This gives better vsync stability in windowed mode at lower CPU usage than is possible with D3D9. Note that the D3D11 driver is disabled by default and has to be enabled in Options, and DXGI 1.3 is only available starting with Windows 8.1.

Regarding emulation vs. real hardware, personally I'd like that discussion to not get too far out of hand here, if for no reason other than that these threads already tend to get way too long even without tangents. That having said, the goal of Altirra is to be able to substitute for real hardware but not to obsolete it, and one of the main strategies for achieving that is high emulation accuracy. Testing on real hardware is essential but not a panacea, simply because few people have all of the hardware combinations that are necessary for full testing coverage: NTSC/PAL/SECAM, floating data bus vs non-floating data bus, OS-B vs. XL/XE OS vs. custom OS, stock memory vs. expanded memory, different makes of 6502, 65816, and physical floppy drives. That's why it emulates a lot of hardware behaviors that have no practical use for the sake of accuracy.

That is probably an excellent occasion for a moment of silence: Atari computers *1979 †2015

 

Personally, I don't mourn things that aren't dead and intend to be working on extending the life of the Atari 8-bit past 2016.

atbasic.bin

atbasicx.xex

  • Like 13
Link to comment
Share on other sites

i rediscovered the magic of real HW when I need to present our work at Revision 2015 party on real hardware and video capture was made from real HW... the "click clack" of an original Atari 800 XL keyboard is magic... then I packed everything back in such box that I can take verything out when I wish.

 

yesterday I did "bring your own device" in the office and young programmers loughed...then I showed them some stuff in Atari basic and later they coded their first graphical output. but they were suprised about the pixel sizes but loved the instant success without compile and turn around times to get something on screen... (ok... they did not get the "editor" thing with line numbers etc...)

 

Altirra is a dream to develope with so hope phaeron will not discontinue.

Link to comment
Share on other sites

I'm not sure how this would be done, but could the "2-bit systems" sound sampler called "Replay" be incorporated somehow into Altirra? It was a cartridge rather than a plug in board of any kind, so I'm not sure how that would work in Altirra, but it was a decent little sound sampler.

Link to comment
Share on other sites

Yeesh, you guys dig up some weird stuff.

 

Evie is a bit over the top with 2 x POKEY + SID + configurable SID filter + AY. Replay... um, I don't have a sound recording path right now, and 2-bit audio is getting pretty close to Apple II level of sound quality. I dunno. I'm not going to say yes or no, but if I add these, you'll see it in a future release, and if I don't, well, you won't.

  • Like 1
Link to comment
Share on other sites

I'm not going to say yes or no, but if I add these, you'll see it in a future release, and if I don't, well, you won't.

 

Thank you, I can't ask for more than that.

 

It's not actually 2-bit, that was just the company name:) I had the Gralin version and forget if its 4-bit or 8-bit. I guess 4-bit since that is all pokey can replay.

 

I believe that it was actually 4-bit if I remember rightly. The name probably came around as I guess that there were 2 employees???

Link to comment
Share on other sites

Yeesh, you guys dig up some weird stuff.

 

Evie is a bit over the top with 2 x POKEY + SID + configurable SID filter + AY. Replay... um, I don't have a sound recording path right now, and 2-bit audio is getting pretty close to Apple II level of sound quality. I dunno. I'm not going to say yes or no, but if I add these, you'll see it in a future release, and if I don't, well, you won't.

Limited Evie support with YM chip emulation (and without configurable SID filters for beginning) would be helpful for coders I think. Other chips like POKEYs, SID, COVOX and GTIA buzzer you have been implemented in Altirra now (of course Evie AY and SID are clocked by slightly different quartz). And Evie is in production currently and will be accessible soon.

There is sofware supports Evie YM chip:

- Let's Emu by Draco (ZX Spectrum emulator),

- PSGplay by me (PSG register dump player for SDX).

Evie SID is supported by:

- SIDPLAYER by XXL (SID modules player for xBIOS),

- SIDplay by me (SID modules player for SDX - not released yet).

However if you'll decide to implement it I can serve with Evie registers description, and I think Pasiu/SSG will be helpful as hardware constructor.

Edited by mono
Link to comment
Share on other sites

All of the emulation modes are high-level: they emulate the behavior of the disk drive but not the actual drive code running in it. There are a couple of reasons for this. First, the base Atari disk drive protocol is high level enough that controller-level emulation isn't necessary -- you can't upload code to the drive like you could on, say, a 1541. This means that excellent compatibility levels are achievable with HLE. Second, there are a variety of controllers used on disk drives, including 6507, 6502, 65C02, Z80, and 8048.

 

Regarding the XF551 specifically, the drive sounds are from real samples recorded by fellow AtariAge members, the PERCOM block behavior is modeled after quirks in the real drive, it's simulated as spinning 300 RPM instead of 288 RPM, and it should support all of the commands. Deficiencies are that the high-speed format doesn't actually apply high-speed interleave, the seek behavior probably isn't completely correct, and the various drive timings haven't been tuned yet. I don't have an XF551, so I have to rely on you guys to spot anything else that's off, unlike the 1050 where I've been able to check against the real drive.

 

For the Happy drive, better emulation is definitely possible but a lack of information is a problem. I haven't found a good description of all the commands. If it turns out that the Happy software requires code upload then it becomes a much bigger pain to emulate, since it would require actually emulating the controller CPU to do good emulation. I've only just started on multi-CPU support with the Veronica stuff. In general, none of the special or non-disk features of drives are emulated in any of the emulation modes currently, so you can't backup protected disks or boot CP/M on the emulated drive.

 

It's worth noting that you need to be careful about having disks mismatched against the emulation mode, as currently Altirra doesn't check whether a drive actually supports the disk you put into it. You can bind a DSDD disk when the emulation mode is set to 1050, but weird things will happen when you do this.

Many thanks for this in-depth answer phaeron! It does clear up some of the questions I have - specifically the interleave support as that is something I have noticed with SDX and the format command/dialogue.

 

I do play with disks a lot so this is obviously something I am pretty focussed on. I also appreciate it is not everyone's cup of tea though or even a very useful feature for them. Hopefully you will add some polish/features at a future point - but that is only a request to register interest as it were. The ability to check for the currently emulated drive's features that you mention would be VERY useful and maybe a first step? I would also think the XF551 would be easier to do for accuracy as I do not think there is any run-time re-programming/uploading of code between it and the A8. The Happy on the other hand I am pretty certain from what I have read does allow uploading - so that is a lot to bite off in one go. Without a physical drive I guess you are working with one hand tied behind your back in a darkened room with a blindfold!!! Currently I cannot find a single XF551 for sale on ebay in Britain at least and I don't think there are any in America either.

 

Again, my thanks for this.

Link to comment
Share on other sites

I would not have thought you would see a Happy programmable feature and to be honest I can't see the point of it, it's all fancy using Happy Backup to program the drive by writing to the drive itself but then what do you use it for, we already have ultra fast I/O support, plus you had to re program the drive to make it 'UnHappy' for a lot of games because of the protection.

 

But who knows, Avery sometimes throws us a curve ball and adds some amazing new unexpected features..

Edited by Mclaneinc
Link to comment
Share on other sites

Hey Paul!!!

 

Yeah - it is a niche thing, but it would be nice to have nonetheless. I do a lot of playing with disks, so having that depth to the virtual environment would really be a nice addition. Given the amount of work necessary to get that uploading of code working I can understand how it will not be an easy thing though. However, full emulation of an XF551 would keep me quiet for a while though! Would you believe I used to spend hours on the real hardware formatting diskettes with the different versions of DOS and then trying them out by copying over basic programmes I had already typed in? Something about being able to squeeze an extra few bytes/'blocks' on to the disks was really pleasing to me. Unlike everyone else I never really hated DOS 3 though - so I must be stranger than I thought! As it stands I currently could buy a happy board for not a terrible amount, but not a functioning 1050 to put one in! Which isn't quite true as some hopeful fellow wants £60 plus another twenty for delivery on ebay right now! So Altrira is what I have to play with.

 

As an aside a while ago I read a late-eighties article from Antic that covered stripping out the mechanical guts of a 1050 and substituting the works from a 3.5inch floppy drive. There was obviously some work required to re-write the firmware but apparently the chap got it all back together in one piece and could then format and write quad-density 1.44mb floppies in SD/MyDOS. Now THAT would be very cool and given my own 1050 is somewhat defunct then its something I would have been quite tempted to try out given you can buy a 1.44mb floppy for £5 these days!

 

UPDATE: Here we go:

 

http://www.atarimagazines.com/v8n5/XF35Kit.html

 

Although I see it is a XF551 this mod re-purposes, so - not the easiest to perform given how imposible it is to find those drives on ebay.

Edited by morelenmir
Link to comment
Share on other sites

Yeah, there were a few hacks of the XF551. I had three: a stock model, one with Bob Puff's 3.5" mod (not the dual drive mod Mat*Rat reviewed in your link) and one that held my hard drive. Since the XF's mechanical guts were just standard PC fare, I took the drive mechanism out and used its power supply to feed a SCSI drive connected to my Black Box by a ribbon cable out the back. Eventually I just connected the 3.5 mechanism direct to the Floppy Board and took the box off the SIO chain.

 

By the time the XF came out, the PC and Mac had set the standards for hardware, and it was not only cheaper for Atari to use the same mechs as the "big boys" but smarter. It was so much easier to repair an XF than a 1050 since you could just chuck the mech for a new one if the heads got damaged or the motor stopped spinning. Unfortunately, Atari not only tried to save money on the hardware end but on the firmware end, which is why we ended up with the FUBAR code that ran the thing and I'm sure makes it a pain to emulate properly.

Link to comment
Share on other sites

Not sure if it's a bug (I'm assuming so), but after encountering difficulties enabling a RAM window at $8000 using The!Cart, I managed to completely nuke the emulator (app crashed and spontaneously closed) under Win7 32-bit by writing to The!Cart control registers using the debugger.

 

Edit: regarding $8000 banking, I tested the same program using the $A000-$BFFF window without issue, so maybe there's a problem with RAM in the secondary bank.

Edited by flashjazzcat
Link to comment
Share on other sites

http://www.virtualdub.org/beta/Altirra-2.70-test10.zip

http://www.virtualdub.org/beta/Altirra-2.70-test10-src.zip

  • Veronica emulation fixes: TRIG3 is now updated, AND instruction fixed, banking register bugs fixed, made more parts of the debugger work with multiple debug targets.
  • Added Go To Source to History pane and fixed a regression with crashing when toggling source breakpoints.
  • Fixed the issues/crash with The!Cart RAM banking. The banking wasn't always updated when flipping the write protect bits and the new cartridge path wasn't initializing the RAM.

The Enable Function Keys option does indeed enable 1200XL function keys, and if you enable them, they hide the SSO keys. I haven't worried about this because the function keys were only on the 1200XL and were seldom used. Also, IIRC if you happen to be able to trigger F1-F4 on an 800XL or 130XE it can crash the computer by messing with the PORTB bits.

  • Like 2
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...