Jump to content
IGNORED

Altirra 2.70 released


phaeron

Recommended Posts

I was asking in another thread why Altirra does not seem to have the ability to connect to real atari drives.. someone posted that Atari ++ can

[As a bonus, the emulation also includes Matthias Reichl’s “atarisio” interface, allowing you to connect a real 1050 or 810 drive to the emulating PC by means of a 1050-to-PC or ProSystem cable.]

 

So for those of you in the know.. why is this not in Altirra yet??? is this difficult to implement here? or is there something and I am not aware?

 

James

Link to comment
Share on other sites

Perhaps I am missing something obvious, but, when the IDE+ emulation is active in Altirra, how do I setup a cartridge so that it is under IDE+ control? Any cart I try to attach seems to disable the internal SpartaDOS X.

 

Also, could it be possible to setup a slave disk under IDE+?

Link to comment
Share on other sites

I was asking in another thread why Altirra does not seem to have the ability to connect to real atari drives.. someone posted that Atari ++ can

So for those of you in the know.. why is this not in Altirra yet??? is this difficult to implement here? or is there something and I am not aware?

 

I guess, phaeron just didn't come around to implement it. After all, it's not something everyone asks for...

Link to comment
Share on other sites

While I was setting up BlackBox under Altirra (not so fun but successful :_( ), I observed that Altirra crashes (black screen) whenever BlackBox device is installed in the Emulator while running under Ultimate 1MB (both Bios v1.02 and 1.08).


Black screen (crash) = True .. If:

BackBox present

"AND"

U1MB --> PBI BIOS =Enabled


OS:

Stock XL

Hi speed OS

Qmeg


Other setup that has no effect on the "black screen":

- SIO drive: HSIO or Disabled for bios 1.08

( High-Speed SIO: Drives 1-4 or Disabled for bios 1.02)

- SpartaDos X: Enabled or Disabled.


------------------

System Boots normally when;


BackBox device is not present

"OR"

U1MB --> PBI BIOS =Disabled


OS:

Doesn't matter

--------------------


Note: Altirra will boot normally when selecting OMNIMON XL as the OS regardless if PBI Bios is Enabled “AND” if BlackBox device is present.

However, U1MB Setup screen becomes garbled under U1MB bios v1.08, (for v1.08, Setup screen show normal pages).


madi


Link to comment
Share on other sites

 

While I was setting up BlackBox under Altirra (not so fun but successful :_( ), I observed that Altirra crashes (black screen) whenever BlackBox device is installed in the Emulator while running under Ultimate 1MB (both Bios v1.02 and 1.08).

Other setup that has no effect on the "black screen":
- SIO drive: HSIO or Disabled for bios 1.08
( High-Speed SIO: Drives 1-4 or Disabled for bios 1.02)
- SpartaDos X: Enabled or Disabled.

madi

madi, is that a REAL HARDWARE Blackbox your trying to use with Altirra?

 

I see you talk about SIO drio HSIO... Would this not be the driver I am talking about in the post above?? Does this allow you to attach real atari hardware to the PC??

 

James

Link to comment
Share on other sites

madi, is that a REAL HARDWARE Blackbox your trying to use with Altirra?

 

I see you talk about SIO drio HSIO... Would this not be the driver I am talking about in the post above?? Does this allow you to attach real atari hardware to the PC??

 

James

Unfortunately Not.

 

I never had a real BlackBOX. I just was learning how it works (under emulation environment) and experimenting with its capabilities.

I also wish if Altirra can handle "real" peripherals such as "Disk drives", real printers, etc.

 

The bottom line is that it is up to Avery to add such devices to Altirra. I thank him very much for the best Atari emulator out there.

 

madi

Edited by Madi
Link to comment
Share on other sites

The latest builds do no longer show "long sector" with LFE DISK active (i.e. sector 706 of Solo Flight 2nd Edition).

 

Fixed:

http://www.virtualdub.org/beta/Altirra-2.80-test47.zip

http://www.virtualdub.org/beta/Altirra-2.80-test47-src.zip

 

This was just a logging issue. The logging code was reporting a long sector when the Lost Data FDC status bit was set, but this broke when I fixed the 810 emulation to use the correct statuses. The Generic and 810 modes use 810 behavior, while all other modes use 1050 behavior.

 

I was asking in another thread why Altirra does not seem to have the ability to connect to real atari drives.. someone posted that Atari ++ can

[As a bonus, the emulation also includes Matthias Reichl’s “atarisio” interface, allowing you to connect a real 1050 or 810 drive to the emulating PC by means of a 1050-to-PC or ProSystem cable.]

 

So for those of you in the know.. why is this not in Altirra yet??? is this difficult to implement here? or is there something and I am not aware?

 

Well, for starters, atarisio is a Linux kernel module, and Altirra is a Windows program. There's a problem here.

 

The Atari serial port protocol has tight enough timing requirements that it is difficult to implement reliably on a PC from a normal program. atarisio mitigates this by running in kernel mode, which allows it more control over timing than a normal program. There isn't an analogous driver for Windows, and even if there were, it wouldn't work with USB adapters since it requires a built-in serial port. Assuming this could be solved, there's still the problem that the emulation has a significant amount of jitter relative to real hardware. On average it runs at the same rate, but within a video frame it runs in spurts and not continuously like real hardware does. This isn't much of a problem for normal disk reads through the OS, but it's a problem for custom disk routines and particularly copy protected disk loaders. That narrows the applicable scope even more, so at this point... why not just image the disk rather than trying to run it live? Not worth the effort and limitations.

 

There is one additional issue which is minor but a blocker nevertheless -- I don't have a 1050-2-PC cable, only an SIO2PC cable. If I need to test the drive protocol it's faster to load the test program onto an AtariMax cartridge, and if I need to write a physical disk it's MUCH faster to do so through the SuperCard Pro.

 

Perhaps I am missing something obvious, but, when the IDE+ emulation is active in Altirra, how do I setup a cartridge so that it is under IDE+ control? Any cart I try to attach seems to disable the internal SpartaDOS X.

 

Also, could it be possible to setup a slave disk under IDE+?

 

Currently the IDE+ emulation is not hooked into the cartridge chain, but is simply mapping memory at EXTSEL priority, which is higher priority than RAM but lower priority than the cartridge. From what I know of the PBI bus, this interpretation should be correct because a device on the PBI bus does not have the ability to intercept RD4/RD5 from the internal cartridge port. This means that the IDE+ cannot disable or map over the internal cartridge.

 

Therefore, I assume this would pertain to the external cartridge port on the IDE+. I could hook the IDE+ into the cartridge chain at intermediate cartridge priority, so that it is below the primary cartridge and above the secondary cartridge. This still wouldn't be quite right because it would allow the primary cartridge to disable the IDE+ SDX ROM, but having SDX on both the internal cartridge and IDE+ is not a very useful scenario. What hardware register bit(s) control the external cartridge, and is it just the $A000-BFFF window or also $8000-9FFF and $D5xx switched?

 

 

While I was setting up BlackBox under Altirra (not so fun but successful :_( ), I observed that Altirra crashes (black screen) whenever BlackBox device is installed in the Emulator while running under Ultimate 1MB (both Bios v1.02 and 1.08).

 

 

Looking at the hardware memory maps of the two, I don't think these are compatible. The main reason is that the BlackBox does not follow the PBI specification with regard to selection and memory mapping. The hardware schematic I have for the BlackBox indicates that it always maps the $D1xx page, which is unfortunately also used by the U1MB for I/O RAM. I/O RAM is primarily used by the PBI BIOS, but can also be used by the startup BIOS since it is also enabled prior to config lock. There is no signal from the MMU to the PBI bus for $D1xx, so the BlackBox has to decode it from the address lines -- which also means that U1MB can't inhibit it. The result is that any reads or writes to I/O RAM are going to go to both the BlackBox and U1MB, which is bad ju-ju. The symptom I'm seeing in emulation is that even with the PBI BIOS disabled, attempts to enter the BlackBox menu lock up due to a misconfigured VIA port B.

 

I can't say that this would happen on real hardware, because there could be errors in schematics, different hardware revisions, or other effects that would make this possibly work or not work. One important thing to keep in mind about pre-testing hardware configurations in this manner: Altirra does not emulate funny smells or smoke coming out of the computer.

  • Like 8
Link to comment
Share on other sites

 

. One important thing to keep in mind about pre-testing hardware configurations in this manner: Altirra does not emulate funny smells or smoke coming out of the computer.

 

Spot on...comical but so so important to realise in the whole scheme of things..

Link to comment
Share on other sites

Currently the IDE+ emulation is not hooked into the cartridge chain, but is simply mapping memory at EXTSEL priority, which is higher priority than RAM but lower priority than the cartridge. From what I know of the PBI bus, this interpretation should be correct because a device on the PBI bus does not have the ability to intercept RD4/RD5 from the internal cartridge port. This means that the IDE+ cannot disable or map over the internal cartridge.

 

Therefore, I assume this would pertain to the external cartridge port on the IDE+. I could hook the IDE+ into the cartridge chain at intermediate cartridge priority, so that it is below the primary cartridge and above the secondary cartridge. This still wouldn't be quite right because it would allow the primary cartridge to disable the IDE+ SDX ROM, but having SDX on both the internal cartridge and IDE+ is not a very useful scenario. What hardware register bit(s) control the external cartridge, and is it just the $A000-BFFF window or also $8000-9FFF and $D5xx switched?

This is not very accurate, as the PBI replacement present in XE computers consists mostly of the cartridge port, and this of course contains the cartridge control signals. Therefore the IDE+ attached to an XE can fully control the cartridge inserted to its pass-through cartridge connector.

 

On XL this is optional, but the IDE+ provides additional connector to attach the cartridge control signals missing on the PBI. So the full cartridge control is also possible on XL (although of course using the additional signals is not mandatory and it would probably then behave like you describe).

 

I think the simplest solution would be to modify the IDE+ emulation behaviour depending on the System->Hardware selection. When the XE hardware is selected, then the IDE+ should have the cartridge control, because that is the normal behaviour on XE hardware. This is of course only a suggestion.

 

The external cartridge control, as far as I know, switches $A000-$BFFF and $D5xx. I do not know what happens to $8000-$9FFF, but if the cartridge is 16k, it probably is handled as well normally, as on an XE computer with such a cartridge inserted.

 

The responsible register is SDXCTL $D1FE (write-only). Its power up value is $00. When b7 is 0, then b0-b5 select internal SDX ROM banks (b0-b6 in 1 MB option). When b7 is 1, the internal SDX ROM gets switched off. In this case, b0 decides what to do with the external cartridge (possibly) inserted into the IDE+ cartridge port: b0=0 enabled, b0=1 disabled.

 

I presume that the slave drive emulation is out of the question? Or maybe there is a simple way to add a second disk image to the IDE+ emulation which I am overlooking?

Link to comment
Share on other sites

The external cartridge control, as far as I know, switches $A000-$BFFF and $D5xx. I do not know what happens to $8000-$9FFF, but if the cartridge is 16k, it probably is handled as well normally, as on an XE computer with such a cartridge inserted.

 

The responsible register is SDXCTL $D1FE (write-only). Its power up value is $00. When b7 is 0, then b0-b5 select internal SDX ROM banks (b0-b6 in 1 MB option). When b7 is 1, the internal SDX ROM gets switched off. In this case, b0 decides what to do with the external cartridge (possibly) inserted into the IDE+ cartridge port: b0=0 enabled, b0=1 disabled.

 

I presume that the slave drive emulation is out of the question? Or maybe there is a simple way to add a second disk image to the IDE+ emulation which I am overlooking?

 

Hmm. I think I'll just put IDE+ at higher priority than the primary cartridge slot, and have the mounted cart always go through the IDE+. The other case is just too weird and non-useful to deal with.

 

Apologies, I forgot to respond about the slave drive request. This has been requested for MyIDE as well, and now that I have everything on the device framework it's more feasible. The main issue is that currently my IDE emulator doesn't support master/slave and I don't know all the details of how IDE works with two drives. I don't know when I'll have this working, but this seems reasonable and doable.

  • Like 2
Link to comment
Share on other sites

Update:
http://www.virtualdub.org/beta/Altirra-2.80-test48.zip

http://www.virtualdub.org/beta/Altirra-2.80-test48-src.zip

  • The internal SpartaDOS file system has been updated and will now does more thorough validation of the filesystem. Previously it only checked the bitmap against the free sector count, but now it will traverse the entire filesystem and check for directory loops and bitmap errors. It also now understands the SpartaDOS 1.1 filesystem (the difference of which was previously ignorable since the bitmap was not validated; now the DOS boot region has to be taken into account).
  • The extra command flyout in the Disk Drives command now has a command to expand all .ARC archives on a SpartaDOS disk. Each archive file is replaced with a directory of the same name and timestamp holding the expanded contents of the archive. This makes it a bit more bearable to deal with toolkit disks containing .ARC files. The disk and filesystem are extended if necessary to hold the expanded files.
  • MyIDE, KMK/JZ IDE, and IDE Plus 2.0 now allow slave drives. The second hard drive added as a child becomes the slave drive on the IDE bus. SIDE, SIDE 2, and MyIDE-II do not allow two hard drives as they are CompactFlash based.
  • Fixed bug with IDE drives reporting terminating nulls in IDENTIFY DEVICE strings, and added the capacity and type to the reported device name. Note that the capacity reported is the LBA capacity, not the CHS capacity (significant for small drives).
  • IDE Plus 2.0 devices now support toggling the on-board SpartaDOS X module and the external cartridge(s).
  • In the debugger, .kmkjzide dumps status for that IDE device (currently NVRAM and external cart enable).

 

Thanks for the answer Rybags re the coldstart question, missed it and always like to thank folks for taking the time to reply..

 

Sorry, didn't notice this. Cold Reset (Shift+F5) is a stone cold power-up. It's equivalent to turning off the computer and all devices, waiting 30 seconds, and powering everything back up again. Only non-volatile storage (tape, disk, EEPROM, flash, and battery backed real time clock RAM) are preserved. I couldn't reproduce the behavior you were seeing with that cart, but that shouldn't happen.

 

 

  • Like 5
Link to comment
Share on other sites

Thanks Avery, I'll recheck the roms I'm using although the standard os roms are picked up by the scan and not added by me but I have seen one the of V2 XL roms do odd things.....Weird, anyway will make sure its a out of the box config re the coldstart issue and come back to you if its still showing. ..

 

EDIT:

 

Just reset the lot, scanned a set of roms that I've seen as good from day one ie the Xformer roms and only them and no sign of that issue, odd as I've only lately used the standard OS's that Altirra scans so it should be picking up known good ones. ..If it happens again I'll 100% check every setting to see if anything is non out of the box but still perplexed as to how it only showed up whatever the config after a shift F5, it sure have booted it like the first boot on that config that worked?

 

Anyway, it seems a me only issue so thanks for looking to you and Rybags..Thank you for your time..

Edited by Mclaneinc
Link to comment
Share on other sites

I'm not seeing a difference between 2.71 and 2.8-test. The sprites are corrupted in NTSC in both, but that's due to insufficient VBLANK time.

 

It's appears to be a PAL only demo. Here's screen shots from 2.71 and 2.8(47) using PAL video option.

 

Bob

post-18691-0-34523100-1468754809_thumb.png

post-18691-0-39068000-1468754820_thumb.png

Edited by bfollett
Link to comment
Share on other sites

Can someone tell me where I can find the posts where Phaeron went through the features that he was adding to Altirra Basic, not in Atari Basic. I've spent a lot of time looking, but can't seem to find them. Perhaps someone remembers?

 

Thanks,

Larry

Link to comment
Share on other sites

Can someone tell me where I can find the posts where Phaeron went through the features that he was adding to Altirra Basic, not in Atari Basic. I've spent a lot of time looking, but can't seem to find them. Perhaps someone remembers?

 

Thanks,

Larry

Version 2.60 [March 21, 2015]:
changes

features added
ATBasic: Improved execution speed.
ATBasic: Added partial support for CONT statement.
ATBasic: Added support for DPOKE, BPUT, BGET, ERASE, PROTECT, UNPROTECT, DIR, RENAME, MOVE, HEX$(), DPEEK(), !, %, &, and $.



Version 2.70 [December 19, 2015]:
changes

features added
ATBasic: Added LOMEM, ERR(), PMGRAPHICS, PMADR(), PMCLR, PMCOLOR, PMMOVE, MISSILE, and BUMP().

The Heilp Button change log..

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