Jump to content
IGNORED

Altirra 2.30 released


phaeron

Recommended Posts

Why would I be getting this response to the PCLINK.SYS in my autoexec.bat file..

 

SpartaDOS X 4.46 23-05-2013

Copyright © 2013 by FTE & DLT

PCLink v.0.6, dev. 6, SIO id $6F

Warning: no server response

 

This is with the standard Ulitmate.rom and SYSTEM/Memory Size=ultimate1mb Harddrive setting to SIDE 2

 

When I have the SYSTEM/Harddrive setting set for KMK IDEv2 and the proper rom selected PCLINK.SYS works ok.

Link to comment
Share on other sites

Somehow I have managed to miss the excellent PDF from Avery 'Altirra Hardware Reference Manual'. I don't pretend to grasp in one reading the emergent behaviour unfolding from the 'corner cases' he describes. Nevertheless it is a fascinating read and I would recommend anyone who is going to use Altirra to programme with give it a read. VERY well written indeed.

 

Now if there were just a similar tome on using the Altirra debugger...

Link to comment
Share on other sites

16-bit INX bug fixed... the insn decoder was checking the M bit instead of the X bit:

 

http://www.virtualdub.org/beta/Altirra-2.40-test7.zip

http://www.virtualdub.org/beta/Altirra-2.40-test7-src.zip

 

Took a look at PCLink, couldn't reproduce the problem... but that's hard because I have a zillion different SDX, SIDE, and U1MB ROM images and I can't tell which is which or find the one that is U1MB SDX + IDE driver. I did find a small bug where the PCLink indicator on screen wasn't updating, which I fixed.

Link to comment
Share on other sites

Got it, happens only when high memory is disabled. Gyruss is incompatible with 24-bit addressing, but it happens to mostly (or perhaps fully) work if memory is present in bank $01.

 

VERIFIER: 64K address space wrap detected on abs,X indexing mode.
	  PC=86bf  X=0c  Target=000b
(1861: 13, 35) PC=86BF A=0A X=0C Y=02 S=F1 P=35 (   I C)  86BF: 9D FF FF		  STA $FFFF,X  [$000B] = $00

VERIFIER: 64K address space wrap detected on abs,X indexing mode.
	  PC=86c7  X=0c  Target=000b
(1866: 20,  1) PC=86C7 A=00 X=0C Y=0A S=F1 P=34 (   I  )  86C7: BD FF FF		  LDA $FFFF,X  [$000B] = $0A

Link to comment
Share on other sites

That's interesting: the official manual http://www.wdesignc....on/w65c816s.pdf says on page 19, in the section on effective address calculation:

 

With Absolute Indexed with X (a' date='x) addressing the second and third bytes of the instruction are added to the X Index Register to form the low order 16 bits of the effective address. The Data Bank Register [/font']contains the high order 8 bits of the effective address.

 

Which seems to mean that e.g. LDA $FFFF,X when X > 0, will always wrap to the beginning of the segment. But on page 52 the same document says:

 

The Absolute Indexed addressing modes are used to address data outside the direct addressing range. (...) Indexing from page FFXX may result in a 00YY data fetch when using the W65C02S. In contrast' date=' indexing from page ZZFFXX [b']may[/b] result in ZZ+1,00YY when using the W65C816S.

 

So, even if on page 19 it must wrap, on page 52 there's a warning that it might not. Am I misreading this, or there's a contradiction here?

Edited by drac030
Link to comment
Share on other sites

Page 52 is correct -- absolute indexing will cross bank boundaries. This has been confirmed to occur and cause MyDOS to break on 65C816 systems that have 24-bit addressing:

http://atariage.com/...00#entry2475968

 

I did extensive research on this and other issues when I did the last round of fixes on Altirra's 65C816 emulation. The WDC datasheet simply has a lot of errors and omissions and doesn't cover many of these edge cases with regard to behaviors and cycle counts. The most useful information I found was from people who had been reverse engineering the SNES:

https://github.com/g...ocs/ob-wrap.txt

 

There is an open question regarding JMP ($FFFF) since apparently the SNES's memory configuration doesn't allow for testing that -- it'd need an '816-equipped Atari or an Apple IIGS to confirm. I suspect it reads from $00:0000 and not $01:0000 since the pattern is for DBK-based reads to carry over and for PBK-based reads not.

Link to comment
Share on other sites

By doing quite a bit of assembler lately I have come across a useful suggestion - a menu command/hotkey to reset the virtual machine and reload the current object file. This would make the incremental code cycle a little less tiresome without calling for directly linking altirra to an editor command line:

 

edit

assemble

if successful

reset&reload

edit

assemble

if successful...and so on

Edited by morelenmir
Link to comment
Share on other sites

There is an open question regarding JMP ($FFFF) since apparently the SNES's memory configuration doesn't allow for testing that -- it'd need an '816-equipped Atari or an Apple IIGS to confirm. I suspect it reads from $00:0000 and not $01:0000 since the pattern is for DBK-based reads to carry over and for PBK-based reads not.

 

Correct, just checked on real machine: JMP ($FFFF) reads the LSB from $00FFFF and MSB from $000000.

 

As about Gyruss, I admit I don't understand, why enabling high memory makes it run better than with 64k address space. If it is address wrapping which causes problems, one would expect an exact reverse behaviour, i.e. correct with 64k (with memory writes landing where they were aimed, i.e. on zero page), failure with high memory enabled.

 

Again, the bug does not show up on a real 65C816 Atari equipped with high RAM.

Link to comment
Share on other sites

Ah, thanks for testing the JMP (abs) wrap case. I need to add this info to my hardware doc at some point.

 

Gyruss works with high memory because the indexing always wraps and the bytes in question in $000B-$000F aren't accessed in any other way. Basically, the game doesn't care whether the buffer is in bank $00 or bank $01 as long as it can read and write them properly. Thus, when bank $01 is present, the game still functions because those instructions still function as intended, just not at the originally intended memory locations.

 

The reason it doesn't work in Altirra with high memory disabled is that Altirra always currently emulates a full 24-bit address bus, so when high memory is disabled bank $01 is either pulled up to $FF (XL hardware mode) or floating bus (XE hardware mode). The $FF value makes Gyruss think that the explosions have never expired. It would work with a 16-bit address bus, but this is not a '816 mode that Altirra currently supports.

 

In any case, the patch to make Gyruss fully compatible with the 65C816, regardless of memory configuration, is simple:

86BF: 95 FF		  sta $ff,x
86C1: EA			 nop

86C7: B5 FF		  lda $ff,x
86C9: EA			 nop

86F7: D6 FF		  dec $ff,x
86F9: EA			 nop

Link to comment
Share on other sites

The reason it doesn't work in Altirra with high memory disabled is that Altirra always currently emulates a full 24-bit address bus, so when high memory is disabled bank $01 is either pulled up to $FF (XL hardware mode) or floating bus (XE hardware mode).

 

I see. But I think that it's unlikely to be the case on real machine. Real 65C816 Ataris either have the high memory, or the bits 16-23 of the address bus are not connected to anything.

 

BTW. I don't think if distinguishing "XL hardware mode" and "XE hardware mode" is 100% correct. My first 65XE I got in 1988 showed $FF in all unused I/O locations.

Link to comment
Share on other sites

I could not find these listed anywhere and so copied them out from the /? dialog:

 

Switch Result

 

/resetall Reset all settings to default

/baseline Reset hardware settings to default

/ntsc Select NTSC timing and behaviour

/pal Select PAL timing and behaviour

/secam Select SECAM timing and behaviour

/artifact:none|ntsc|ntschi|pal|pal Set video artifacting

/[no]burstio|burstiopolled Control SIO burst I/O mode

/[no]fastboot Control fast kernel boot initialization

/[no]casautoboot Control cassette auto-boot

/[no]accuratedisk Control accurate sector timing

/[no]basic Enable/disable BASIC ROM

/[no]vbxe Enable/disable VBXE support

/[no]vbxeshared Enable/disable VBXE shared memory

/[no]vbxealtpage Enable/disable VBXE $D7xx register window

/[no]soundboard:d3c0|d500|d600 Enable/disable SoundBoard

/kernel:default|osa|osb|xl|lle|hle|other|5200|5200lle Select kernel ROM

/hardware:800|800xl|5200 Select hardware type

/memsize:16k|48k|52k|64k|128k|320k|576k|1088k Select memory size

/[no]stereo Enable dual pokeys

/gdi Force GDI display mode

/ddraw Force DirectDraw display mode

/opengl Force OpenGL display mode

/[no]vsync Synchronize to vertical blank

/debug Launch in debugger mode

/[no]debugbrkrun Break into debugger at EXE run address

/f Start full screen

/bootrw Boot disk images in virtual R/W mode

/type "keys" Type keys on keyboard (~ for enter, ` for ")

/[no]hdpath|hdpathrw <path> Mount H: device

/[no]rawkeys Enable/disable raw keyboard presses

/cartmapper <mapper> Set cartridge mapper for untagged image

/portable Create Altirra.ini and switch to portable mode

/ide:d1xx|d5xx|kmkjzv1|kmkjzv2|side,ro|rw,c,h,s,path Set IDE emulation

/[no]pclink:ro|rw,path Set PCLink emulation

/hostcpu:none|mmx|sse|sse2|sse2|sse3|ssse3|sse41 Overide host CPU detection

/cart <image> Load cartridge image

/tape <image> Load cassette tape image

/disk <image> Load disk image

/run <image> Run binary program

/runbas <image> Run BASIC program

 

I can NEVER get this post window to format tabs and spaces properly. Still - it is readable, just about!

Edited by morelenmir
Link to comment
Share on other sites

Thanks for all the work you do on this!

 

Any idea why I can't see any of the help? I can navigate the topics tree, but nothing shows up to the right. I'm trying to figure out the arguments for the "ba" command.

Link to comment
Share on other sites

I can NEVER get this post window to format tabs and spaces properly. Still - it is readable, just about!

Surround any text like that in "code" blocks, and it uses a mono-spaced font. It can still be a major hassle getting everything nicely lined up though.

Link to comment
Share on other sites

I'll give that a shot Stephen! I see some of the chaps posting up perfect code snippets and grind my teeth in envy!

 

Phaeron - have you heard about this fellow over with you in America who assembled his own 1450XL from Atari spares?

 

 

Critically he says he produced a definitive and cleaned up batch of documentation. Given this and the fact the 1450's were put together from parts the majority of which you have already emulated - is it possible we might see these machines as options within Altirra? Obviously I don't mean tomorrow or even in the current 2.xx versions as 'Freddie' and CO61618 would require new work. I have however already come across an XLD bios of some form.

 

It would be amazing to be able to play with one of these machines, even in virtual form.

Link to comment
Share on other sites

Wow! That would be just about the coolest electronics project I can imagine. Even if I had to run the thing in a biscuit tin I would, lacking an authentic case! Someone needs to take a serious look at producing these for hobbyists - or at least the unsourceable components like the motherboard. I REALLY envy you the 1450 Atari Geezer!!!

 

Phaeron - is it possible to alter the key bindings in the Source-level debugging window? I don't like the F11-F12 keys for stepping and so forth. In the normal Display/Global key bindings I have moved them to the num-pad which feels more comfortable to me.

Link to comment
Share on other sites

I see. But I think that it's unlikely to be the case on real machine. Real 65C816 Ataris either have the high memory, or the bits 16-23 of the address bus are not connected to anything.

 

65C816-equipped Ataris aren't that common, so I'm not sure there's much of a convention at all. Nevertheless, it's easy to emulate both since Altirra uses two-level page tables for '816 mode, so I've just split the None option into 16-bit and 24-bit addressing modes:

 

http://www.virtualdu...-2.40-test8.zip

http://www.virtualdu...0-test8-src.zip

 

BTW. I don't think if distinguishing "XL hardware mode" and "XE hardware mode" is 100% correct. My first 65XE I got in 1988 showed $FF in all unused I/O locations.

 

It's not, but it's close enough. The main machines I'm targeting with those options are the 600/800XL and the 130XE, which are the stable ends; it gets murkier with the 800XE and 65XE in the middle. In the end I figured it was reasonable enough to label these XL/XE rather than to use something more technically accurate but obscure like "has floating data bus." Eventually I would like to add additional differences, like the one-cycle difference in POKEY timing and some minor discrepancies in GTIA timing. From what I've heard, this actually comes from some differences in 6502 timing, which means there are probably a bunch of XLs and XEs out there that diverge from this definition... but I mainly want to have coverage over the possible differences, not to necessary match every possible combination of these particular quirks.

 

Currently, for all the cases other than pulled up / floating data bus that I have seen between my 800XL and 130XE, Altirra currently emulates the 800XL behavior as it is the more stable of the two. On occasion, I have been able to change the 130XE's behavior with a can of compressed air....

 

Any idea why I can't see any of the help? I can navigate the topics tree, but nothing shows up to the right. I'm trying to figure out the arguments for the "ba" command.

 

Do you have Altirra on a removable or network drive? Microsoft HTML Help now has a stupid limitation where it will only open .chm files on local drives, and it displays a meaningless Action Canceled error otherwise. It also does this if the file has the "came from Internet" tag on it, although Altirra tries to rip that off. Worst case, pull the source archive and view the help source .xml files in your web browser; they have XSL transforms attached to make them viewable, which is how I actually work on them.

 

The help file doesn't actually have very good help for individual debugger commands, though. That's built into the debugger itself -- type .help ba, or just .help if you want a list of commands.

 

Critically he says he produced a definitive and cleaned up batch of documentation. Given this and the fact the 1450's were put together from parts the majority of which you have already emulated - is it possible we might see these machines as options within Altirra? Obviously I don't mean tomorrow or even in the current 2.xx versions as 'Freddie' and CO61618 would require new work. I have however already come across an XLD bios of some form.

 

Sorry, not at this time. I looked into this a while back, and it's a lot of work for a machine that was arguably vaporware -- even the ones that work apparently don't all work exactly the same way. In the end, what the 1400/1450 machines actually are regular XLs with additional PBI devices attached. The serial port is boring, the parallel disk is somewhat boring, and the voice synthesis would be a huge amount of work.

 

Phaeron - is it possible to alter the key bindings in the Source-level debugging window? I don't like the F11-F12 keys for stepping and so forth. In the normal Display/Global key bindings I have moved them to the num-pad which feels more comfortable to me.

 

Not right now. I need to redo the way keys are handled in the debugger windows as there are a bunch of hardcoded keys.

Link to comment
Share on other sites

Fair enough. I can see your point - basically we already have the majority of a 1450 running right now. Altirra would be the only way the majority of us will ever experience one of these gorgeous machines though. I do get very excited when I see the amazing work these chaps have done who build their own from spares. I actually considered in a laughable, blue-sky kind of way assembling a shell if you can get hold of the cases around enough of a PC to run Altirra - perhaps around a Raspberry Pi/Arduino kind of show. Therefore you'd have a sort of virtual 1450 in a box - a bit like those Atari controllers that play 300 games and can be connected directly to the television!!!

 

Also fair enough with the hotkeys. I think you've done good work with that aspect even as it stands though - already we can differentiate between shortcuts purely for the display and those globally over the whole machine. I guess that is the direction you will follow it though with; adding a section for debugging bindings.

 

I only came across this after I took the plunge and started to use mads. When you assemble and then pass the result to Altirra in debugging mode you automatically get a source-level debugging screen. I'd suggest making that an option in the debugging settings - whether you automatically want the source-level window to pop up at startup or not. When you think; It would be nice to somehow more fully integrate that window in to the Altirra interface as my monitor does get a bit crowded between it and the main window! However you need to be able to read completely across the source window in to any remarks at line end AND see the Altirra display AND the console... The docking could get very crowded. Maybe you could have a side-by-side arrangement for the console and the source-window at the bottom of the screen as I think it is more important to be able to read across than see a long way down... It would be nice at least if the source windows could remember how you last sized it and its position on the screen.

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...