THE!CART... New 128MB FLASH Cartridge

[venom4728a]

Hmmm, I am working on a different computer today, it also seems I cannot save new work books. so it may be related to only this pc. I will try to open the workbooks on the other pc later today.

 

Robert

Ok, back on my home PC and have no issues loading workbooks. Must be some security settings that I need to tweak on the other PC.

 

Robert

[venom4728a]

WOW, My current workbook has my cart about 51% filled. 1750 files. It takes quite a bit of work to fill up one of these carts .

 

Robert

[ZylonSlayer77]

 

Looks like Beach Head doesn't work, it crashes on loading the first scene. I was able to replace it with an ATR > Maxflash conversion which does seem to work. On Infiltrator (the non working one), I put Steve's version on an Atarimax flash cart for testing and it doesn't work there either.

 

The previous Infiltrator that had not worked was in fact Steve's. So, it doesn't work on a real Atarimax either. Thanks, I've got 5 8 Mbits here but I don't have any 1 Mbits for testing. Looks like some of these were never tested extensively then. I'll look into Beach Head and see if I can find one in XEX format that works. If not, I'll use the ATR. Well, I will definitely try to have that fixed and probably attempt to clean up menu title entries a bit on next release.

[+JAC!]

2014-01-23

• First version of "Google like search" and scrolling in the result list of the "Extended Menu" is now implemented. Some bugs still in there like cleaning the screen lines that are not part of the result, but for sure worth trying.
• The workbook options now allow all types of menus if the flash module type is "user defined". The "Simple Menu" and "Extended Menu" will of course only work if the actual module later is a The!Cart module.

Note that you don't have to type any prefix like in the example below but just any word that's in the title. I tested it with workbook with 14.000 entries, but they were all named like "ROM-001122", wil be more fun with actual titles.

 

The typing, the search and the update of the result are running as three separate "threads in parallel" - at least from your point of view.

[Frankie]

WOW, My current workbook has my cart about 51% filled. 1750 files. It takes quite a bit of work to fill up one of these carts .

 

Robert

 

Can you share?

[w1k]

where i can find download?

[Marius]

On my Mac latest version will not export anymore. It does not show a file-dialoge window (a finder window) to store something.

 

Hmmm exiting the program, and restarting did work.

Edited January 23, 2014 by ProWizard

[Marius]

How do you test this with emulator? With some trouble I got that atari800 3.0 running on my Mac, but it keeps telling me unknown format when I tried to use the CAR or the BIN version.

 

Thanks for help!

 

Oh and one more thing:

 

Is Genres not working yet? Or where can I find how to use them?

 

I get all my entries on the first page of the menu, and I don't see the genres at all. For a test I tried to changed it (I also fooled around with the 'favorites' option) but when I try to reflash the cart, the flasher says: nothing has changed to the cart, so I have nothing to do. So now I can still not test it.

 

I suppose it does not work yet?

Edited January 23, 2014 by ProWizard

[Frankie]

How long should it take to flash the cart?

 

I'm running it at 3x and it seems like it's going to take a couple hours to finish.

I'm using the "All Carts" workbook. I have AspeQT and SIO2PC. I exported to the single large ATR.

 

AspeQT says it's 16,385 sectors, 8192 bytes/sector and it's doing 1 sector every 3-4 seconds.

 

Frank

[+remowilliams]

2014-01-23

• First version of "Google like search" and scrolling in the result list of the "Extended Menu" is now implemented. Some bugs still in there like cleaning the screen lines that are not part of the result, but for sure worth trying.
• The workbook options now allow all types of menus if the flash module type is "user defined". The "Simple Menu" and "Extended Menu" will of course only work if the actual module later is a The!Cart module.

 

Just taking a look now - wow that search function is very nice!

 

 

How long should it take to flash the cart?

 

 

A relatively large flash is going to take a while at that speed, i.e. a couple of hours for a 20% or so full cart image (non incremental).

[Frankie]

 

Just taking a look now - wow that search function is very nice!

 

 

 

 

A relatively large flash is going to take a while at that speed, i.e. a couple of hours for a 20% or so full cart image (non incremental).

 

How can I make it faster? If I try and set AspeQT to use something like pokey divisor 0 (or 1) it tries to send faster but then steps down to 19.2 right away.

What speed should I set the VCP to?

 

I also have a SIO2USB and APE. Would that be faster?

[+remowilliams]

 

How can I make it faster? If I try and set AspeQT to use something like pokey divisor 0 (or 1) it tries to send faster but then steps down to 19.2 right away.

What speed should I set the VCP to?

 

I also have a SIO2USB and APE. Would that be faster?

 

 

As Hias was explaining earlier in the thread, high speed SIO can be a tricky thing with many factors involved. I am having success at the moment with aspeqt (single large ATR) set to DSR handshake with POKEY divisor zero (125kb/s), though I haven't yet flashed an entire image at that speed.

[Frankie]

 

 

As Hias was explaining earlier in the thread, high speed SIO can be a tricky thing with many factors involved. I am having success at the moment with aspeqt (single large ATR) set to DSR handshake with POKEY divisor zero (125kb/s), though I haven't yet flashed an entire image at that speed.

 

I got it working. I was using the flash option from the cart. It didn't have the hi-speed sio patch loaded. So I booted off the ATR image that has the flasher and loaded HISIO.COM from thier. Then I could flash at hI-Speed!

 

I'll see if it get's all the way through to 3585.

[+JAC!]

>latest version will not export anymore. It does not show a file-dialoge window (a finder window) to store something.

If export is not peformed for regular reasons (e.g. if there is an entry with unsupported content type), there should be an error message in the status bar.

If the action is enabled in the menu but nothing seems to happen at all, this migh be an exception in the background. In such cases, please start The!Cart Studio from a command console via "java -jar TheCartStudio.jar". Then you will see the exception information and can send it to me.

>Is Genres not working yet? Or where can I find how to use them?

Not included yet. They are next on the list once the search function is bug free. In fact the genres and the favourites are filters just like the search term (only they are simpler to search for as I plan to encode them into single bytes at fixed positions). Currently the genre info (list of genres and favourtie/genre assignment) is not included at all. Hence the flasher sees no difference.

Edited January 23, 2014 by JAC!

[Kyle22]

Let me start off by saying that I don't have a cart. I hope to someday purchase one. But, If you have an Incognito, why couldn't you put your CF card into your Windows machine, copy your ATR file on it, then put the card back into the Atari, mount the ATR in SDX, and flash it fast?

 

Just an idea....

[+remowilliams]

Let me start off by saying that I don't have a cart. I hope to someday purchase one. But, If you have an Incognito, why couldn't you put your CF card into your Windows machine, copy your ATR file on it, then put the card back into the Atari, mount the ATR in SDX, and flash it fast?

 

Just an idea....

 

Maybe, if Incognito could mount a 128MB ATR.

[flashjazzcat]

 

Maybe, if Incognito could mount a 128MB ATR.

 

And can you tell me where it is stated that it cannot? There is in fact no upper limit (beyond 28-bit LBA sector addresses in FAT32) on the size of a mounted ATR. I rather think the limiting factors are currently existing Atari file systems. An ATR can in theory be up to 256MB in size (16,777,216 x 16 byte paragraphs), so if it happened to be self-booting, I see no problem. Certainly worth testing.

Edited January 24, 2014 by flashjazzcat

[+remowilliams]

 

And can you tell me where it is stated that it cannot?

 

 

Wasn't a statement that it can't, but that if it can then it might work.

[flashjazzcat]

 

 

Wasn't a statement that it can't, but that if it can then it might work.

 

Ah - so you meant: "Maybe, if Incognito can mount a 128MB ATR".

 

Anyway: this sounds too extreme not to have a go at.

[Roydea6]

 

Just couple of examples to show the end of the search list via Joystick...

[flashjazzcat]

Looking more closely at the flash issue, while it is true that Incognito will support ATRs up to 256MB, it does not support non-standard sector sizes (from a glance through the thread, I noticed mention of 8KB sectors). If 8KB sectors are indeed used, it would follow that a custom SIO routine is also used, so I doubt the flasher would work with any PBI hard disk if that is the case. You'd need to prepare a flasher ATR with double density sectors (or quad density, although the boot loader would be slightly trickier to write), and use the lower 2 or 3 bits of DUNUSE as the upper 2-3 bits of the sector number, calling the standard OS SIO vector to read sectors from the volume.

Edited January 24, 2014 by flashjazzcat

[venom4728a]

 

Can you share?

 

I will, Still a few more days until is done,

[HiassofT]

Looking more closely at the flash issue, while it is true that Incognito will support ATRs up to 256MB, it does not support non-standard sector sizes (from a glance through the thread, I noticed mention of 8KB sectors). If 8KB sectors are indeed used, it would follow that a custom SIO routine is also used, so I doubt the flasher would work with any PBI hard disk if that is the case.

Although the flasher uses a highspeed SIO routine by default you can also disable it from the menu and use the standard OS routine. The flasher then just does a standard JSR $E459 which should work with all SIO and PBI devices. This works fine both with 256 bytes and 8k sector sizes - the stock OS SIO code supports this out of the box, no need to fiddle around with DUNUSE or use other non-standard tricks.

 

BTW: the feature of arbitrary length SIO transmissions has been used quite a lot, even in the 80s, for example for loading a handler or highspeed SIO code from a device with a single SIO call, or for using very large sized blocks on tape.

 

As for Incognito/Side: I have neither of them so I can't test myself. If they don't support 8k sector sizes the alternative is to use multiple 16MB images. Either install them, for example, into D1: up to D9: or install the first image into D1: (or whatever you want) and then swap in the other images when the flasher requests them. The flasher supports D1: up to D15:

 

As for flashing speed: reading and flashing of an 8k block takes approx. 1.1 seconds when using 8k sectors and SIO with Pokey divisor 0. Reading needs approx. 0.7 seconds, flashing approx 0.4 seconds (and erasing, needed every 16 8k blocks, approx 0.5 seconds). If you use the standard 16MB images, SIO overhead is somewhat higher so reading will take longer (haven't measured this yet).

 

Then you can do the math: just measure the time needed for reading an 8k block, add the flashing time and 1/16th of the erasing time, and multiply all that by the number of (non-empty) banks. For a full 128MB flash you need approx. 16384*(0.7+0.4+(0.5/16)) = 18534 seconds - which is some 5 hours.

 

so long,

 

Hias

[flashjazzcat]

Although the flasher uses a highspeed SIO routine by default you can also disable it from the menu and use the standard OS routine. The flasher then just does a standard JSR $E459 which should work with all SIO and PBI devices. This works fine both with 256 bytes and 8k sector sizes - the stock OS SIO code supports this out of the box, no need to fiddle around with DUNUSE or use other non-standard tricks.

DUNUSE is part of the extended sector addressing method supported and well documented since the IDEa interface, and KMK's XDCB further supports full 32-bit sector addressing via the SIO. But regardless of this: you're quite right, of course, and I was wrong to speculate that a special SIO routine would be required. I would suggest, however (disregarding ATR mounting for a moment), that many PBI hard disk controllers will have a problem with the large sector sizes, simply because drivers generally support the physical disk sector size of 512 bytes, plus the emulated sizes of 256 and 128 bytes. To retrieve longer sectors would require a different form of generic emulation, whereby several physical sectors are combined as a single, larger sector (in a similar way to FAT clusters, although cluster handling is done by the file system, not the low-level sector transfer routines).

 

Moreover, the problem of compatibility is confounded by the fact that ATR emulation performed in the PBI BIOS requires the buffering (and offsetting) of physical disk sectors in order to retrieve emulated sectors in three different standard densities. This is not to say that - for example - 8KB sectors could not be supported both by the ATR emulation subsystem and the standard logical disk handler, but I wonder if the effort involved is worth the bother in all but a handful of situations.

 

BTW: the feature of arbitrary length SIO transmissions has been used quite a lot, even in the 80s, for example for loading a handler or highspeed SIO code from a device with a single SIO call, or for using very large sized blocks on tape.

This is interesting, and certainly something I wasn't familiar with.

 

As for Incognito/Side: I have neither of them so I can't test myself. If they don't support 8k sector sizes the alternative is to use multiple 16MB images. Either install them, for example, into D1: up to D9: or install the first image into D1: (or whatever you want) and then swap in the other images when the flasher requests them. The flasher supports D1: up to D15:

Yeah - that sounds a reasonable approach. Meanwhile, I need to think about the wisdom and ergonomics of attempting to support larger sectors.

 

As for flashing speed: reading and flashing of an 8k block takes approx. 1.1 seconds when using 8k sectors and SIO with Pokey divisor 0. Reading needs approx. 0.7 seconds, flashing approx 0.4 seconds (and erasing, needed every 16 8k blocks, approx 0.5 seconds). If you use the standard 16MB images, SIO overhead is somewhat higher so reading will take longer (haven't measured this yet).

 

Then you can do the math: just measure the time needed for reading an 8k block, add the flashing time and 1/16th of the erasing time, and multiply all that by the number of (non-empty) banks. For a full 128MB flash you need approx. 16384*(0.7+0.4+(0.5/16)) = 18534 seconds - which is some 5 hours.

Well, I can't speculate much about the performance of emulated 8KB sectors via PIO, since I don't think it can be tested yet, but with 512bps volumes, Incognito should attain something in the region of 25-30KB/s. Naturally if the flash image could somehow find its way onto a logical hard disk partition (or the FAT area, where it could be read via the FAT DOS in Candle's XEX loader), efficiency would be roughly doubled. Obviously the flashing overhead is a given, which we can't do much about.

Edited January 24, 2014 by flashjazzcat

[HiassofT]

DUNUSE is part of the extended sector addressing method supported and well documented since the IDEa interface, and KMK's XDCB further supports full 32-bit sector addressing via the SIO.

I'm well aware of that, that's why I wrote non-standard

 

Actually I think it was a very bad idea to redefine the semantics of the well documented SIO read/write sector commands and use some additional fields. The proper approach would have been to only use DAUX1/2 for SIO read/write and add additional commands, let's say extended read/write, which use whatever additional parameters they want.

 

Any program/DOS/whatever wanting to support more than 65535 sectors could have just queried the interface if it also supports "extended read/write" and then use those special commands.

 

The biggest issue with the DUNUSE approach is that it only works with PBI devices. The physical SIO protocol (on the SIO bus) only transmits DAUX1/2 in the command frame - so it just isn't possible to break the 65535 sectors limit.

 

During the flasher and studio design phase it was quite clear that we'll have to implement a standard conforming fallback format for all SIO2SD, APE, PBI device, ... users - and that's the split 16MB ATR programming images.

 

We also thought about programming files that reside withing an Atari filesystem but quickly dropped the idea because no Atari filesystem supports 128MB files so far, and fast random access - which we need to skip over unused blocks - is only available in SpartaDos (which would have been too limiting, even if SpartaDos supported 128MB files).

 

Since we also wanted an easier to use format which didn't involve a lot of disk swapping I created the 8k sector ATRs. It was very easy to implement and fits the standard use case quite well: Create the collection on the PC, fire up AtariSIO or AspeQt on the PC, and run the flash cart update on the Atari.

 

So we went the raw image route, it's DOS independent, provides quick random access, and - in case of 8k sectors - supports 128MB (and more).

 

Another approach would have been to add some sort of USB programmer function to the cart, but this would have increased costs and complexity.

 

Moreover, the problem of compatibility is confounded by the fact that ATR emulation performed in the PBI BIOS requires the buffering (and offsetting) of physical disk sectors in order to retrieve emulated sectors in three different standard densities. This is not to say that - for example - 8KB sectors could not be supported both by the ATR emulation subsystem and the standard logical disk handler, but I wonder if the effort involved is worth the bother in all but a handful of situations.

I can imagine dealing with this nasty ATR header offset must have caused you quite some headaches - but from what I've read you seem to managed doing it very well!

 

IMO 8k sectors are of quite limited use on the Atari. You certainly wouldn't want to put an SDFS or something like that on it OTOH they are nice for storing large amounts of data.

 

I'm not sure if it's worth all the hassle to implement them in the PBI BIOS since for the!cart there's always the 16MB fallback route. There would be a small speed gain, but I don't think it'll be huge.

 

so long,

 

Hias