flashjazzcat

This is entirely proper on the U1MB setup. If you want to boot direct to the SIDE3 loader, select 'Boot to loader' in the U1MB settings.

I think SIDE3 is pre-flashed at the factory with whatever is published at the time a new batch is produced. Don't worry about asking questions, anyway. You need to flash the BIOS.ROM file to the U1MB Main BIOS slot, and ULTPBI.ROM to the PBI BIOS slot on the U1MB. That's it. Remove the SIDE3 cartridge before you run uflash. I am not especially happy about the fact the new firmware and all plugins (which have been completely redesigned even since that interim firmware was released last year) are still not formally released on the U1MB download page, but I am currently participating in a kind of protracted psycho-drama concerning the JED update for Incognito and I cannot release the update on my side of things until this is sorted out. However excruciating it is for the spectator, imagine actually coding it.

Is that the one that's 7.5K in size? EDIT: Well, after using exceptional Google-fu to find a copy (6.7K in size) and after it spammed the screen upon installation, it appears to work. TDLINE2 raises MEMLO by about 750 bytes. I think a lightweight y2k-compliant TDLINE could be useful here, to complement the ULTD.SYS driver.

I thought Lotharek had a link to this on the product page, but in any case - you need the pre-release U1MB firmware for SIDE 3: https://atari8.co.uk/firmware/side3/ See 'downloads' section.

You need more RAM long term, I'm afraid. I suggest Ultimate 1MB for the optimal user experience with SIDE3.

I appreciate it. Thank you. MEMLO is completely indeterminate since the entire driver is relocated down to low memory at run time. I started with $1BA2 here with Sparta 3.2g and $1CBD after installation. TDLINE.COM (which still says 'Tuesday') of course pushes things up further ($1FA3).

Whoops... missed a relocation label. Fixed and re-uploaded.

Please test this and see if MEMLO is acceptable now: ultd_1.23_fix.zip The resident part is about a dozen bytes shorter than the last version (I completely jettisoned one buffer). Does anyone actually have a Y2K fixed TDLINE, BTW? The one from the other thread still claimed it's Tuesday.

OK - let me sort that out. $2000 is the magic MEMLO number anyway. One older version - IIRC - had a serious bug which broke reset-protection.

Yes. Bug fixes pushed it up. If this is a problem, I will try to shrink it

On the toolkit: https://atari8.co.uk/apt/toolkit/

The driver does not use the weekday stored on the DS1305. You'll still need a patched TD line as well.

Yeah - fully understand that.

Presumably AVG uses a message-passing system between the 6502 and the MCU (Ultimate and UNO certainly do). So there'll be a register somewhere at $D5xx (maybe a command register and a data register); you could essentially 'POKE' a command token followed by a FAT path/filename and this would tell the cart's MCU to read said cart image into SRAM, disable writes to the SRAM, and set things up using the desired banking scheme. The cart sensing lines would reflect the presence of an external cartridge, and typing 'CAR' at the SDX prompt would start the cart. Essentially, this is a 'how does the loader mount carts?' question. Whether the designer wishes to document or disclose the API is another matter.

Through the forest of 'FPGA commands' and other such novel terminology, it appears he wants to mount cartridge images using some potentially self-written third-party tool.

Well, it all looks pretty. I gather the majority of users don't give much of a shit how something is accomplished, as long as it works.

Most interesting. One important difference between this and SIDE3's DMA engine is that SIDE3 doesn't halt the CPU. It uses the first part of the bus cycle to complete a read/write operation. The CPU and the DMA engine have coinstantaneous access to the same memory (albeit not the computer's on-board memory; this distinction will not matter with a PBI implementation which can supplant all the RAM on the host machine). The first iteration of the PDM player I recently added to the SIDE3 loader exploited this by DMAing data into a FIFO buffer while the CPU simultaneously fed it to POKEY. As it happened, though, DMA was total overkill for that application so I reverted to the CPU doing everything using just a 256 byte buffer and interleaved PDM data. DMA will surely be useful for video playback, though. Thanks for the synopsis of this and Ultimax mode, though, and the video links. Most impressive. I guess it's not surprising that a design a little younger than the A8 boasts such nice facilities. Yeah - totally. I mean only that it's possible to do just what you describe.

Interesting. I know little about the C64 architecture but if there are native DMA capabilities which work with on-board RAM, that's pretty cool. An Atari cart can only map to $8000-$BFFF and $D5xx, so can map its own ROM/RAM there and DMA anything it likes to those addresses (which is exactly what SIDE3 does). But a PBI device can quite easily override all the base RAM on the machine and DMA to the entire system memory space (thereby allowing 1.7Mbps data transfers). SALLY at stock speed cannot even copy RAM from one place to another at much more than 64KB/s or so, so obviously if you want to go faster than that, DMA to external RAM is the way to go. The AVG cart's MCU is presumably responsible for loading cartridge ROM images; if the 6502 were doing this, things would be rather slow. SIDE3 uses the DMA engine to load carts at much the same speed (~1.7MB/s). It's obvious that CPU-bound tasks are a bottleneck regardless of whether or not a message-passing API is implemented with an external MCU. The advantage of the MCU design (UNO, Ultimate, AVG) is that the 6502-side software is greatly simplified, with file system tasks handled by the MCU using (potentially) off-the-shelf libraries like FATFS. None of this necessarily translates into noticeable performance or functionality gains, though (although tmp - once he noticed his search facility was broken on large data sets - fixed it such that performance is beyond the reach of any 6502-bound solution), since the CPU is still funnelling data. But of course it does allow stuff like a complete SIO server running on the cart.

He means it works exactly like SIDE2 when in SIDE2 emulation mode. So you can watch a video about SIDE2 with or without U1MB and that's how it works. You'll have no RTC or NVRAM in stand alone mode, but that's about it.

Oh - I would have done the same, even if to ensure the foil doesn't 'float off'. I was applying it to the inside of a cardboard box.

Internally reflective surfaces really help, I think. My 'magic light box' wasn't very effective until I lined the inside with aluminium foil. With the foil, it's arguably as effective as sunlight.

Yes - it turned out well, especially given that it's about eight years since I did any spray-painting: Yes: I hear of and see good results with fully submerged parts. Will have to try this when the opportunity arises.

Oh heck. Something I just noticed now from the photos as well is that U1MB doesn't think it can turn stereo on and off (the stereo POKEY setting is dimmed and 'enabled'). This suggests something is amiss either with the PokeyMAX core or the wiring between M0 and the PokeyMAX. U1MB tests for a second POKEY while toggling M0 and if the second POKEY doesn't come on and off the bus, it's assumed no software control is possible.

Great. We're getting somewhere. Now I think we should double and triple check the PokeyMAX wiring (A4, etc); check the header pinout, make sure the wiring corresponds to the core installed on the PokeyMAX (this last one is very important). I assume you have the standard U1MB-controlled Stereo POKEY emulation, but it's worth checking everything.

The redundant lengths of ribbon cable are probably the main offenders (they're carrying the whole address and data bus), but as you say: some installs seem to get away with it. I start to wonder if the machine is hanging up when attempting an SIO boot, so would definitely be interested to see what changes with POKEY.