New GUI for the Atari 8-bit

[flashjazzcat]

Bearing in mind you'll need an Incognito board to use this with an 800 (since the kernel goes in the RAM under the XL/XE OS), you'd need to enable ports 3 and 4 first. And as Prodatron says, it's trivial to implement support for this.

[mellis]

The mouse control is driver based, so a different port shouldn't be an issue at all!

 

The problem is that POKEY's PORTB register is used for memory management XL or XE systems, while on the 400 and 800 used it was for the 3rd and 4th joysticks. From what I've been reading, I can't imagine that this GUI would work at all on a 48K system (such as the 800 or an expanded 400), and if PORTB is being used for joysticks, then it is most certainly not being used to access the uppermost 16K on 64K systems or any expanded memory on 130XE (or RAM upgraded) systems.

[flashjazzcat]

Incognito provides a dedicated register for ports 3 and 4, so no worries at all.

[Muzz73]

Nice! I'm waiting to see if there are any Incognitos left from this run anyway, so this just got a little more awesome!

[Kyle22]

I believe that the Incognito is the best Atari upgrade ever. I absolutely love mine.

 

I have NOT been able to make joystick ports 3 & 4 work. If anyone has info, please let me know.

 

Thanks

[flashjazzcat]

I tested this for Candle a year or more back and it may have involved a CPLD update at the time. I haven't kept any info about it unfortunately... Maybe one of the Incognito threads has some info.

 

MrFish kindly gave the ROM a spin for me and sent a detailed crash report back. Already traced most problems back to a bug in the memory manager's FREE routine (which was - remarkably - decrementing the bank header's free page count rather then incrementing it for every page released; must have been on fire that day).

 

I'm also working around a chewy issue with the auto-updating list boxes, which clear the item selection every time they're repopulated. I've come up with a kind of process hash code which will mean a task will always have a completely unique ID (distinct from the PID) so the Profiler can easily do incremental list updates (preserving the item selection bit unless the item is removed from the list).

[flashjazzcat]

What's the minimum effort I can get away with when building cart images of this demo? MaxFlash 1Mbit is a given since that's what I'm using for development, but what else? And I suppose Amiga and ST mouse versions, as per the previous one?

[+bob1200xl]

65816?

[flashjazzcat]

Feel free to run it on one.

[+Stephen]

No - anybody can run a GUI on a 16-bit chip such as the 65816. Let's go the difficult route and make this use 6502!!!

[flashjazzcat]

Yep: that's the whole point after all.

[Kyle22]

AFTER, and only after the 6502 version is perfected, I would love to see this thing fly on an 816. Just tweaking the blitter routine alone should be an improvement.

 

Just a thought

[+MrFish]

Feel free to run it on one.

 

Thanks for the idea. The thing is, I just switched it over in Altirra, and you've got this thing running so well on a 6502 at this point that the 65816 hardly feels like an upgrade -- at least running it in this unoptimized state. All of the recent font and window rendering improvements have really made a difference. This bodes well in light of the same tests performed with the first demo you released.

Edited February 4, 2015 by MrFish

[flashjazzcat]

AFTER, and only after the 6502 version is perfected, I would love to see this thing fly on an 816. Just tweaking the blitter routine alone should be an improvement.

 

Just a thought

What I'm saying is you can run it on anything you like now. No illegal Sally opcodes are used and no cycle counting employed. I don't intend to make any tweaks to anything simply because there should be no need to do so. The blitter - like everything else - should simply work faster on a 65816.

[flashjazzcat]

Here's Altirra running the full window drag @7.14Mhz (65816):

 

 

Here's the rub: the blitter code's on the cartridge, so unless "Shadow cartridges in fast RAM" is selected, you don't see a whole lot of difference.

 

Idle CPU usage with multiple Profilers is naturally very low, and I notice no issues with the mouse pointer here or at 14MHz - at least in emulation, which is the only place I can test it.

Edited February 4, 2015 by flashjazzcat

[+MrFish]

Here's Altirra running the full window drag @7.14Mhz (65816): [YouTube Video]

 

Here's the rub: the blitter code's on the cartridge, so unless "Shadow cartridges in fast RAM" is selected, you don't see a whole lot of difference.

 

Idle CPU usage with multiple Profilers is naturally very low, and I notice no issues with the mouse pointer here or at 14MHz - at least in emulation, which is the only place I can test it.

 

Alright, I thought there might be another explanation, as it almost seemed too amazing. None the less, the GUI's speed has improved dramatically over the last demo, especially considering we are now running multiple instances of applications.

[flashjazzcat]

Alright, I thought there might be another explanation, as it almost seemed too amazing.

I'm not sure what you mean by "explanation". The slow cart ROM was throttling code execution speed. This is what it looks like when the code runs at 7MHz.

[+bob1200xl]

Yay!!

 

Looks like we will need to emulate a banked cart in RAM. Is the selection matrix available somewhere?

 

Bob

[+MrFish]

I'm not sure what you mean by "explanation". The slow cart ROM was throttling code execution speed. This is what it looks like when the code runs at 7MHz.

 

Another explanation as to why there didn't seem to be any appreciable difference when running with a 65816.

[flashjazzcat]

Right. I thought you were referring to what we were looking at: it running fast in the video.

[flashjazzcat]

Looks like we will need to emulate a banked cart in RAM. Is the selection matrix available somewhere?

Anything which provides at least 8x8KB banks at $A000 will do. Sixteen banks are better. Bank switching register can be anywhere, and startup bank is unimportant (all banks have the same 16 byte record at the end).

[+bob1200xl]

Should work OK... How will the code be formatted - Bank 2 = !D0 & D1 & !D2? Or, does it use the low-order address bits - Bank 5 = A0 & !A1 & A2?

 

Bob

[flashjazzcat]

Not really fussy. The AtariMax 1Mbit uses a write to $D500-$D50F to select the bank. Other carts, like Sic!, use a single register. I just need to change a few lines of code to make it work with any scheme. Being able to turn the cart off completely is also useful.

Edited February 4, 2015 by flashjazzcat

[Joey Z]

so I hate to add another project to the ever growing list of 'things I might do someday,' but I think it'd be really cool to get this working on the VBXE, the obvious advantages being hardware blitter, greater resolution, color support, etc. I know you are busy enough as it is, and I don't know how you'd feel about this, but I'd be willing to take on the task of VBXE support on a 'when I have time' basis.

[flashjazzcat]

Sure - it makes sense to take advantage of it one day. The trouble is, the graphics get their speed (in part) from not channelling writes through a "put pixel" routine. There's a lot of direct screen access so you'd basically have to rewrite the entire graphics library, tailored for VBXE. It'll be a long time before I even have the necessary stuff documented, but yeah: duly noted!