wAxpander with wAx2

[crusti]

My Wax2 arrived yesterday.
Havent put it in my Vic yet but I have a free weekend .
I have read the manual several times over tho, i know im going to have so much fun with this.

Thank you Chysn.

[Bradeep]

The cart supports SDIEC (obviously) but I didn't see a method to enter directories directly from the BASIC interpreter...loading one of the utilities into memory also fails for some reason; works fine without the cart. Any ideas? The Penultimate Cart has the utility built-in, do you think that would be a possibility?

[chysn]

The cart supports SDIEC (obviously) but I didn't see a method to enter directories directly from the BASIC interpreter...loading one of the utilities into memory also fails for some reason; works fine without the cart. Any ideas? The Penultimate Cart has the utility built-in, do you think that would be a possibility?

You'll have to let me know if I'm on the right track here. I was today years old when I learned that you can even have subdirectories in a Commodore file system! But this seems to work for "entering" SD2IEC subdirectories on an SD card:

Code: Select all

OPEN15,8,15,"CD/VICLAB/":CLOSE15
.F

Is that what you're asking about?

[chysn]

I purchased a license for JiffyDOS for VIC-20, and I'm testing it with wAx 2.

My main concerns were (1) both systems being able to intercept their respective extension commands (@ or .) and (2) disk operation compatibility.

So far, they seem to play nice together, which is a good statement on the quality of JiffyDOS. My focus on hardware testing will be disk operations, but I'll surely go through everything, just to make sure.

(wAx 1, as expected, mostly kills JiffyDOS by usurping all of its wedge characters (@/'←), so I'm not going to test that version any further)

[Bradeep]

You'll have to let me know if I'm on the right track here. I was today years old when I learned that you can even have subdirectories in a Commodore file system! But this seems to work for "entering" SD2IEC subdirectories on an SD card:

Code: Select all

OPEN15,8,15,"CD/VICLAB/":CLOSE15
.F

Is that what you're asking about?

IMG_5202.jpg

Late late late reply, but yes, that was exactly it. Thanks, I wasn't sure how that worked, now I do.

Also, wAx2 doesn't seem to work with my TheC64 or TheVIC20, presumably because it's an older version of VICE running on those systems. Is there a fix for this or just one of those "too bad so sad" situations?

[Mike]

Also, wAx2 doesn't seem to work with my TheC64 or TheVIC20, presumably because it's an older version of VICE running on those systems. Is there a fix for this or just one of those "too bad so sad" situations?

Make sure you have RAM in BLK5 before you soft-load the cartridge image of wAx2. If the emulation does not autostart the cartridge, use SYS64802.

[chysn]

wAx2 doesn't seem to work with my TheC64 or TheVIC20, presumably because it's an older version of VICE running on those systems. Is there a fix for this or just one of those "too bad so sad" situations?

Unfortunately, I don't have one of those devices. As Mike suggests, it's probably a memory configuration issue rather than incompatibility. wAx doesn't do anything unusual, code-wise, and an emulator that doesn't support it would fail to run a great many things.

A fast sanity check:

Code: Select all

?PEEK(40960) PEEK(43009)
 76   76

If the result isn't a pair of 76es, then the contents of Block 5 are not correct.

[Bradeep]

I asked on the THEC64 Facebook group and got an answer...apparently the system does not like the CRT file, had to use the PRG and add some padding to get it to exactly 8192 bytes. Works now, thanks!

EDIT: Spoke too soon...can load the assembler (both PEEKs work, SYS40960 shows the .A prompt, can use .U to reconfigure RAM), but when actually trying something like in the example (.A 1800 LDA #$2A) get an error:

?ASSEMBLY
ERROR

Annoyed...but will still keep digging.

[Bradeep]

I might be the only one who cares, but the file actually needs to be 8194 bytes to worked correctly...so I did that and now I can mount the CRT and run wAx without issue.

Do you maybe want me to put the file on your git just in case another fringe user wants it?

[chysn]

Do you maybe want me to put the file on your git just in case another fringe user wants it?

Yes, please! I had a helluva time getting the CRT file to work with VICE, and I think it’s worth having a known-working file just for The64. Thanks!

[Mike]

If I am not mistaken, the version of VICE the official firmware of "TheVIC20" or "TheC64" is based on is around 2.4.x-ish. Version 2.4 was released in 2013. In the meantime, the definition of "*.crt" files has changed from effectively non-existent (a raw binary dump without load address) over some VIC-20-specific version (called *.vrt with some defined header) to finally being a subset of the C64 VICE codebase.

For this reason I never adopted the *.crt suffix for any of my own cartridge projects. I either write them as *.bin file (i.e. raw dump without load address, mostly suitable to be burned on EPROM on the PC, but VICE can easily attach them as cartridge provided the user knows where to), or as a *.prg file with load address. The latter easily loads with LOAD"...",8,1 from direct mode or autostarted within VICE - provided there's actually RAM at the place to *.prg file is loaded to, and they also do not require any padding to be filled up to 4 KB or 8 KB.

Bradeep, you did not actually state how you tried exactly to operate the original file, which made guessing the exact actions necessary to get it running - somewhat difficult. Your description it "doesn't seem to work" isn't the most exact one, so to speak.

While *.crt files of whatever definition definitely require a loader to be usable on real hardware, the same also applies to *.bin files. The latter can be read in by OPENing the file in a loader, and poking the values to a pre-defined address range - a faster solution is to read in only the first two bytes with this method, and then doing an absolute KERNAL load to the preset start address+2 which adds the rest. Such a boot loader would look roughly like this:

Code: Select all

1 DN=PEEK(186):Z$=CHR$(0)
2 AD=40960:N$="WAX2.BIN":GOSUB5
3 SYS64802
4 :
5 OPEN2,DN,2,N$+",S,R":GET#2,A$,B$:POKEAD,ASC(A$+Z$):POKEAD+1,ASC(B$+Z$):CLOSE2
6 SYS57809(N$+",S"),DN,0:POKE782,(AD+2)/256:POKE781,AD+2-256*PEEK(782):POKE780,0
7 SYS65493:RETURN

... possibly with extra memory allocation/protection (POKE55,...:POKE56,...:CLR) prepended in line 1 and adapted copies of line 2 with appropriate values of the load address AD for multi-part cartridge dumps in other memory blocks than BLK5. The *.bin files are supposed to be stored as SEQ files in a CBM DOS disk image to signify they do not feature a load address (",S" appended to the file name specifies the SEQ file type).

[Bradeep]

Yes, please! I had a helluva time getting the CRT file to work with VICE, and I think it’s worth having a known-working file just for The64. Thanks!

Looks like it forked when I uploaded, but file is there now.

Bradeep, you did not actually state how you tried exactly to operate the original file, which made guessing the exact actions necessary to get it running - somewhat difficult. Your description it "doesn't seem to work" isn't the most exact one, so to speak.

I attached the CRT as a cart, which doesn't work properly. "Work properly" in this case means it does not load anything into memory, and in fact it seems like the assembler is totally ignored. As previously stated, it appears that the CRT for TheC64 device is essentially just a PRG with a .CRT extension; it also requires a certain size to load for whatever reason. When I padded the file to 8192 bytes, it loaded, but dropped directly into the assembler and wouldn't load anything properly. This is because allegedly the emulator needs two bytes of padding on the front of the file as well. Hence, expanding to 8194 bytes worked, as this pads the file to the correct 8192 and leaves 2 bytes in the beginning for the emulator to attach it.

I don't profess to be in any way some sort of VICE guru here, so I am just relaying the information I got and what I did to make it work.

[chysn]

Looks like it forked when I uploaded, but file is there now.

I see it! I'll pull the file from your fork and put it into my repo after work.

For future reference, what you want to do is a pull request, and then I would integrate it directly into my repo. But this works, and I appreciate you taking the time to provide it.

Does this have some special meaning to The64? MVB0B1B2B3

[Mike]

Does this have some special meaning to The64? MVB0B1B2B3

Postfixed to a filename, "B0B1B2B3" indicates TheXXX-VICE to add RAM to "Block 0" (i.e. RAM1..3, $0400..$0FFF), and BLK1..3 (i.e. $2000..$7FFF). Not sure about what "MV" means.

[Bradeep]

MV tells the system to boot into VIC-20 mode. You can also add TN or TP for NTSC/PAL if needed.

This doesn't work on the Mini, which only boots into C64 mode.