Jump to content
IGNORED

New (alt) BIOS for Ultimate 1MB/Incognito


Recommended Posts

I'm still a little unclear as to whether you're using a Lotharek U-Switch or something you've built yourself. I'm going to add a wait for VBLANK between each write to M0 anyway, but since things work without the pause here it'll be helpful if those with problems can test. I'm perfectly happy to provide custom plug-ins for special switching equipment, but unless I can be satisfied that stereo detection doesn't work with the recommended hardware (Lotharek Stereo Pokey and U-Switch/Candle Stereo board), it's not something I'm especially keen to remove from the standard build.

 

My self-built board works, it's the U-Switch I received from Lotharek that's not working correctly. I did some further testing and found that not only was it sluggish to respond to signal changes (even where I just grounded the wire from BIN directly to ground), but it wasn't consistent in switching. I finally figured out that if I flex the U-Switch circuit board, it works instantaneously. I tried resoldering all of the SMDs, but that didn't resolve the issue, so perhaps there's something wrong on the board itself. Fortunately, I have another U-Switch and will try that one instead. As soon as I receive some parts for my desoldering gun.

  • Like 2
Link to comment
Share on other sites

Actually, the problem was my fault. I didn't realize that a jumper was supposed to be added to this version of the board. It worked without the jumper, just slowly. With the jumper it works fine. Even stranger, was the fact that if there was any capacitance at all at the middle jumper pad, whether touching it with my finger or a screwdriver, it would work perfectly. Anyway, I figured out that I just had to jump across between the two pads next to the input. The original version (and mine) didn't have this jumper at all.

  • Like 1
Link to comment
Share on other sites

Well: I did wonder. :) A CMOS digital-analogue switch which takes up to a second to transition is about as much use as a chocolate fire-guard. I'm using a U-Switch soldered to the disable jumper of my KMK/JZ IDEa interface (with the U-Switch jumper in the inverted logic position) to control the presence of the HDD, and the BIOS plug-in code which tests for the KMK/JZ uses the same detection method, in this case toggling S0:

	.local TestIDEaControl
	lsr IDEaControlFlag
	lda ConfigBuf[0].Aux
	and #$FF-$04		; disable IDEa (via U-Switch connected to pin S0 of P4 header)
	sta UltimateAux
	jsr DetectIDE		; IDEa should be disabled, so test it
	bcs @+
NotActive
	rts
@	
	lda ConfigBuf[0].Aux	; now try to enable IDEa
	ora #$04
	sta UltimateAux
	jsr DetectIDE		; test IDEa again (it should be disabled)
	bcs NotActive		; if IDEa is still present, the BIOS setting has no effect
	sec
	ror IDEaControlFlag
	rts
	.endl

Very neat little devices with many applications, and cheap too.

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

Great: thanks for the update. Wonder what's wrong with MacRorie's?

 

I opened up the machine and had a look. It is almost exactly as you have it setup. The only difference is the +5/GND for the USWITCH and I have the grounds for the speaker jacks connected. Neither of these should make a idfference.

 

Also, the stereo works (I just verified it with the new "Bomber" game.) The LED is illuminated//the BIOS sees it as "on." But there is no way to toggle it. Here is a pic of the card and the entire setup

post-16779-0-20289200-1455836056_thumb.jpg

post-16779-0-53145600-1455836059_thumb.jpg

Link to comment
Share on other sites

I opened up the machine and had a look. It is almost exactly as you have it setup. The only difference is the +5/GND for the USWITCH and I have the grounds for the speaker jacks connected. Neither of these should make a difference.

Thanks! So where exactly are +5v and GND connected? I guess it shouldn't make a difference, but it might - and something's clearly different since the BIOS can't turn off the stereo on your machine.

Link to comment
Share on other sites

Thanks! So where exactly are +5v and GND connected? I guess it shouldn't make a difference, but it might - and something's clearly different since the BIOS can't turn off the stereo on your machine.

 

 

Crap, I knew you were going to ask that . . . right after I closed it up and shut down. :_( I'll look tonight. :thumbsup:

Link to comment
Share on other sites

Thanks! So where exactly are +5v and GND connected? I guess it shouldn't make a difference, but it might - and something's clearly different since the BIOS can't turn off the stereo on your machine.

 

 

 

+5 is coming off of the joystick port. GND is to a common ground I installed for all the projects on the ground plane.

Link to comment
Share on other sites

Sorry Jon, if this has been asked before. I was wondering where the SIDE Loader can load from. Is it able to load an XEX that starts at $0800? Is it possible to change the address of the loader module itsself (like say, to page 4 or 6, or somewhere)?

 

I just tried to load the W.I.P. Pentagram game with no luck. The author says it loads at $0800.

Link to comment
Share on other sites

No chance with $800, which is unreasonably low, but the author of Pentagram is fully aware of this and explained that the final version will load at a higher address.

 

Not much point in moving the loader code IMO, since $400-$6FF is mostly legitimate buffer space that XEX INIT segments might reasonably utilise anyway. The FAT loader at $700 is only 1KB long and the vast majority of sensibly written games and demos appear to work. I don't have the code space to make the loader relocatable.

Link to comment
Share on other sites

Update:

 

Ultimate 1MB Firmware v.0.50.zip

 

SIDE loader adds support for 8KB unbanked cart ROMs (no bank-switching): just put *.ROM file in FAT partition. Some attempt at reset-proofing has been made which certainly works with the ROM version of Altirra BASIC (although users should flash AtBASIC to an Ultimate BASIC slot as a matter of urgency anyway).

 

FAT16 cluster bug fix which appeared in the packaged update hosted at pigwa finally sees a proper release, along with bug fixes relating to the resident read-only FAT CIO file system handler. It's possible to run - say - ALTBASIC.ROM in RAM and get a DIR listing of the FAT folder from which the cart was launched. Typing "DOS" reboots the XEX loader. :)

 

XEX loader is quite a bit smaller (now around 800 bytes), so compatibility with some of the more corpulent games and demos is better than it was.

 

Aforementioned DUNUSE fix enables use of very large (GB range) FAT16 partitions with SDX/FATFS.SYS. I've added a single frame delay to the stereo Pokey switching test which I'll dispense with if it doesn't fix detection problems for the one user currently having issues with it.

 

Quite a lot of code revisions here so I won't be too upset if people find bugs. ;)

 

On the subject of bugs, Prowizard and I are currently investigating the strange issue of SpartaDOS 3.x hanging on reset when booted from the loader (as an ATR or APT partition) when BASIC is forcibly disabled by the PBI BIOS. This hanging only occurs on real hardware and is avoided by leaving BASIC enabled in the loader or simply doing a "BASIC ON" when SpartaDOS boots with BASIC off. The issue does not show up in Altirra and I'd be very interested if anyone can shed light on it.

 

 

Changes (see Changelog.txt):

 

BIOS

 

v.0.50

 

* Added: experimental single frame delay on stereo Pokey switching test

 

 

PBI BIOS

 

v.1.58

 

* DUNUSE reinstated for compatibility with 24-bit SDX sector addressing when not using XDCB

* Dropped CIO call to open screen editor when disabling BASIC on boot

* BASIC disable also sets MEMTOP

 

 

LOADER

 

v.0.39

 

* Fixed: Ctrl-U (Unmount all) keyboard shortcut

* Fixed: MEMLO not set correctly when FMS disabled

* Fixed: Directory buffer overflow not properly handled

* Fixed: "Help" menu title disappearing when long filename scroll countdown timer reached zero

* Fixed: FMS: file catalogue corrupt if called on subdirectory

* Changed: Directory buffer now starts immediately after data in low RAM instead of at $4000

* Changed: LFN scrolling delay adjusted from 50 jiffies to 40

* Changed: LFN scrolling speed increased (was 10 jiffy delay, now eight)

* Changed: Changing directory sort order now results in a re-read of the catalogue the next time the file list is displayed

* Changed: Memory move and clear routines rewritten for brevity and speed

* Changed: Top of XEX loader reduced to $0A6A

* Changed: Top of FAT CIO handler reduced to $104B

* Added: Loader support for 8K ROMs

* Added: Copyright notice

 

v.0.38

 

* Fixed: Bits 16-23 of sector number not properly cleared in FAT16

 

 

PS: Thanks to Kyle22 for spotting the disappearing "Help" string bug, to Phaeron for Altirra SIDE2 CF card detection/reset fix, and to ProWizard for his incredible bug radar.

 

PPS: Thanks also to Kuba and Pin for late night stress tests.

Edited by flashjazzcat
  • Like 4
Link to comment
Share on other sites

I already have the stereo Pokey detection working, so the delay shouldn't be necessary. :)

I wonder if this version will fix one issue I have noticed on a couple of .xex games when loading from Side2 FAT32. In two games the player would be double-size, i.e. all the pixels would be doubled. One is Shamus, but I forgot what one of them was. The glitch would occur whether loading from the U1MB loader or directly off of the Side2 loader. It would not occur if loading over the SIO via AspeQt's .xex loader or from a MyIDE II via its FAT32 loader. I can check with the new version once you've posted the update.

 

To clarify, I mean that only the player's sprite would be doubled, nothing else.

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

Hopefully the problem ProWizard reported moments after I uploaded the update was a memory clear bug triggered by turning off the FAT filesystem. That issue is fixed here (loader v.0.40):

 

Ultimate 1MB BIOS 0.50, Loader 0.40, PBI 1.58.zip

 

I only have access to emulation right now but running into a series of BRK instructions would probably have caused the kind of issues he reported.

 

I already have the stereo Pokey detection working, so the delay shouldn't be necessary. :)

I realize this, but you'll notice MacRorie continues to have problems. ;)

 

I wonder if this version will fix one issue I have noticed on a couple of .xex games when loading from Side2 FAT32. In two games the player would be double-size, i.e. all the pixels would be doubled. One is Shamus, but I forgot what one of them was. The glitch would occur whether loading from the U1MB loader or directly off of the Side2 loader. It would not occur if loading over the SIO via AspeQt's .xex loader or from a MyIDE II via its FAT32 loader. I can check with the new version once you've posted the update.

 

To clarify, I mean that only the player's sprite would be doubled, nothing else.

Just tried Shamus and the main character (Player 0) was double width here as well because the game completely fails to initialise the player width, assuming $D008 to be zero already when the loader already doubled its size. Loader 0.40 above clears out GTIA prior to loading an XEX and the main character in Shamus is now the proper width. Nice catch, that: let me know if the problem is fixed with the other game as well.

 

Software which relies on uninitialised memory is a pet hate of mine (a couple of recent game demos crash just because a certain area of RAM contains non-zero values), but clearing out GTIA only takes a few bytes and seems like a sensible step to take anyway.

  • Like 4
Link to comment
Share on other sites

I located the other game I'd had problems with - Wizard of Wor, but it was only player 2 that was screwed up. I then updated the U1MB and everything works on both Shamus and Wizard of Wor, along with the other fixed issues. Thank you!

 

Will you be releasing a Side2 update? I'm also thinking about finally installing an Incognito...

Link to comment
Share on other sites

Thanks for the confirmation. SIDE2 and Incognito updates to follow.

 

There are a couple more things I want to try and squeeze into the loader, and once this is done and the last couple of unresolved issues are sorted out, we should be good for a v.1.0 release. Still working on documentation as well.

  • Like 2
Link to comment
Share on other sites

I have update my 3 U*.rom with these just downloaded, but now a question about Fat16. Can my Fat32 now be changed to at Fat16 and called with FATFS.SYS and read from SDX or is this just for the usideloade?? What is DUNUSE?? and with my Fat32 and game roms load but don't start. (like crash or freeze), but the Basic roms I put in the Fat32 start and do as expected..

Link to comment
Share on other sites

Can my Fat32 now be changed to at Fat16 and called with FATFS.SYS and read from SDX...?

Yes: FAT16 may be used by the loader and via the FATFS.SYS driver, since there is as yet no FAT32 driver for SDX.

 

What is DUNUSE?

Unused byte in DCB at $307. This byte was used (and described in the documentation) by the old KMK/JZ IDE BIOS for bits 16-23 of the sector number to cater for some future DOS which required 24-bit sector numbers. When designing the SDX drivers and Ultimate PBI, I asked Konrad about DUNUSE and it appeared that it was now deprecated owing to the possibility of an older DOS not clearing DUNUSE, causing the HDD BIOS to deliver the wrong sector. I recently learned that the FATFS.SYS driver does place bits 16-23 of the sector number in DUNUSE and that the SDX kernel drivers still support it, and that IDE Plus 2.0 supports it for backwards compatibility with KMK/JZ. Therefore I have reinstated DUNUSE as an extension of the 16-bit value in DAUX1/2 in order to ensure compatibility. This despite the fact the fact we also have the XDCB as defined by KMK, which introduces two new 8-bit AUX registers in the DCB, observed by the handler as extensions to DAUX1/2 when bit 7 of DDEVIC is set. However, the original (non-APT) KMK/JZ BIOS does not support the XDCB, hence FATFS.SYS relies on DUNUSE for backward compatibility with that hardware.

 

...with my Fat32 and game roms load but don't start. (like crash or freeze), but the Basic roms I put in the Fat32 start and do as expected..

Many game ROMs unsportingly write to the cart area ($A000-$BFFF) in an attempt to ensure they're not running in RAM (i.e. that they haven't been ripped). Of course these ROMs are running in RAM and therefore fail. Altirra BASIC, ASM/ED, and many games do not include such copy protection measures and work just fine, however.

  • Like 1
Link to comment
Share on other sites

and many games do not include such copy protection measures and work just fine, however.

 

That is probably because some people someone thinks that a version on cart is a safe copy protection! What a smooth, smooth, smooth thought.

Edited by ProWizard
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...