My Views on Homebrewer authors and their games

[disjaukifa]

No I do not have the documentation, can you post links to where this documentation is???

Hmm...

Actually I'm afraid I've no idea. I got my copy almost a decade ago. Starcat was hosting them back then, but took them down due to bandwidth costs.

 

I tell ya what, I'll stick them up on rapidshit for you, they're only 75 meg or so, so it shouldn't take too long.

 

Hey Tyrant,

 

I really appreciate that, thats awesome!!! Post the link once their up please

 

-Disjaukifa

[disjaukifa]

 

You can go to Jaguar Sector II and ask for help in the programming section. Gorf teaches Jag programming there.

 

http://www.jaguarsector.com/index.php?act=idx

 

 

Or you can go to the Atari Jaguar Programming section on this forum and ask for help: Gorf loves assembly on the Jag's big chips. There probably is not a question he couldnt answer.

 

http://www.atariage.com/forums/forum/54-atari-jaguar-programming/

 

Speaking of Jaguar Sector II, I made an account there about two days ago, went through the activation and was waiting on an Admin to approve me account, I went there this morning and my account was gone, so I tried registering and it allowed me to register my account again meaning my old was deleted.

 

Could someone please PM a Admin or Mod to see you can get my account "disjaukifa" activated? There seems to be a good amount of information and resources are that forum I would love to see!!!

 

-Disjaukifa

Edited October 2, 2009 by disjaukifa

[Tyrant]

No I do not have the documentation, can you post links to where this documentation is???

Hmm...

Actually I'm afraid I've no idea. I got my copy almost a decade ago. Starcat was hosting them back then, but took them down due to bandwidth costs.

 

I tell ya what, I'll stick them up on rapidshit for you, they're only 75 meg or so, so it shouldn't take too long.

 

Hey Tyrant,

 

I really appreciate that, thats awesome!!! Post the link once their up please

 

-Disjaukifa

 

Here you go. I've included both the scanned copies from '95, and the "v8" version from '93 released in 2001. I'm convinced that the v8 version is earlier, and thus outdated by the scanned copies, but you're welcome to draw your own conclusions.

 

http://rapidshare.de/files/48454707/MANUAL.zip.html

 

Hope they're helpful to you.

[GroovyBee]

Useful links here too :-

 

http://freejag.atari.org/forum/index.php?topic=36.0

[Zerosquare]

I agree with kskunk on almost everything he said on the hardware aspect, except one thing : you can still find 5V-compatible Flash chips, and they're not overly expensive.

 

A 2 megabytes Flash chip costs a bit less than 10 euros on Farnell (and that's considering only what they have in stock right now, there are some cheaper ones that are currently out of stock).

 

Additionally, IIRC, the exisiting homebrew cartridges use a 32-bit data bus like the original cartridges. which requires two 16-bit memory chips, or four 8-bit ones. You don't have to do it that way : you could reduce the data-width to 16 or even 8 bits, and use a single bigger, cheaper and easier-to-find chip. Of course ROM accesses are going to be slower, but that could be partially compensated by reducing the number of wait cycles. And anyways, it's best to copy everything you can into RAM anyways since ROM is much slower in all cases, so I don't think it would be a real problem for new games if taken into account.

[Tyrant]

And anyways, it's best to copy everything you can into RAM anyways since ROM is much slower in all cases

 

Symmetry of TNG made an interesting test program a few years back, in which he blitted a bitmap several dozen times from cartspace into ram, and then blitted the same image the same number of times from ram to ram. He was using an alpine, and found that actually, the cartspace ram on the alpine was slightly faster than the main systems ram, most likely due to avoiding page misses in main ram. I'm not sure how this compares to cartspace roms, but I would assume its similar.

 

Remember, Jaguar ram is divided into pages of 2 kilobytes, if you make successive accesses within that same page, the memory controller can respond much quicker than accesses at more distant locations. However, cartridge space is evidently not paged in the same way, and can be accessed without changing the current page of main ram that is active.

 

edit: Also, going back to the v8 vs scanned manual issue: the scanned pdf's state that the page size is 2kbytes, whereas v8 (iirc) simply mention page misses once or twice but never elaborate on the issue or the page size in the jaguar console.

Edited October 2, 2009 by Tyrant

[Zerosquare]

RAM-to-RAM blitting is an interesting case, as you'll indeed waste lots of time because of the constant pages misses. But I believe using the GPU/DSP RAM as an intermediate buffer should solve that problem.

 

For other things though, like running code or displaying graphics using the OP, I think ROM is really slower than RAM.

[Tyrant]

RAM-to-RAM blitting is an interesting case, as you'll indeed waste lots of time because of the constant pages misses. But I believe using the GPU/DSP RAM as an intermediate buffer should solve that problem.

 

For other things though, like running code or displaying graphics using the OP, I think ROM is really slower than RAM.

Yes, that all makes sense.

 

Someone should really compile a new version of all the docs, and include a section on page misses and how to avoid them. After all, if ram to ram blitting (at 64 bits per blitter tick) was slower than alpine to ram blitting (capped to the 32 bits of the cart space), then it follows that a page miss is more than twice as slow as a page match. When executing code out of main ram (risc code or 68k code), the odds are that any data loaded or moved will be a long way away from the code, thus causing two page misses on every load and every store, and up to three page misses on 68k instructions. In fact the only 68k instructions that won't cause two page misses are ones that only operate on register operands or immediate data.

 

That's a lot of cycles wasted waiting for the memory controller. You could probably get double the performance from the 68k simply by running your code from either cart space or the cache in tom or jerry... assuming the 68k can cope with their "all memory is 32 bit" behaviour.

[Tursi]

A 16-bit wide cartridge runs fine on the Jag at half the normal wait states, and gives roughly equal throughput to the original ROM carts. This is what Skunkboard does. In fact I've done testing that shows it even runs in the "test" mode of 1 wait state (IIRC), although the OP can't read it at that rate, and other custom chips may also have trouble (I was running 68k code).

 

In theory that means you could run two modern flash chips at 32-bits and twice the data rate to beat the original carts' performance, but it doesn't really seem to be worth it? Cost versus performance.

 

As for the 5v flash, Zero, you said the chips are under 10 euros each, that's over $20US today just for the chip -- note that KSkunk was estimating roughly $10US per board, fully populated, using the 3v parts. I think his point stands.

[kskunk]

As for the 5v flash, Zero, you said the chips are under 10 euros each, that's over $20US today just for the chip -- note that KSkunk was estimating roughly $10US per board, fully populated, using the 3v parts. I think his point stands.

 

Actually they're cheaper than that estimate. It's $6.50 USD per chip if you buy more than 10. That's a pretty good deal!

 

If you're willing to design a new PCB, your game fits in 2 megabytes, you don't need a 32-bit bus, and you don't want the complexity of level converters and regulators, Zero's design looks hard to beat.

 

If you don't use professional assembly, you could make that kind of PCB in a toaster oven for around $10/unit. There's some labor involved in that, but it can't be worse than clipping ROMs off old PCBs.

 

I heard a rumor that one recent Jag release was made in a toaster oven.

 

My design is still cheaper at higher quantities/larger cart sizes, but Zero is pointing out a better solution for low quantity/low design effort. That's more of what Jag developers need.

 

A 16-bit wide cartridge runs fine on the Jag at half the normal wait states, and gives roughly equal throughput to the original ROM carts.

 

In my tests the double data rate 16-bit bus is always at least as fast as 32-bits, and in some cases twice as fast. The chip Zero found is 90ns, which is plenty fast for double data rate use.

 

Nobody has mentioned the lack of EEPROM for save state yet, but if you have a flash chip and you wire it properly, you can use part of the flash for save state.

 

- KS

[+rdemming]

And anyways, it's best to copy everything you can into RAM anyways since ROM is much slower in all cases

 

Symmetry of TNG made an interesting test program a few years back, in which he blitted a bitmap several dozen times from cartspace into ram, and then blitted the same image the same number of times from ram to ram. He was using an alpine, and found that actually, the cartspace ram on the alpine was slightly faster than the main systems ram, most likely due to avoiding page misses in main ram. I'm not sure how this compares to cartspace roms, but I would assume its similar.

 

Strange. Since the blitter can blit 64 bits at the time from 64-bits wide ram and only 32 bits at the time from 32-bits wide rom you would expect blits from ram are around twice as fast (if different access times are not taken into account)

 

 

Remember, Jaguar ram is divided into pages of 2 kilobytes, if you make successive accesses within that same page, the memory controller can respond much quicker than accesses at more distant locations. However, cartridge space is evidently not paged in the same way, and can be accessed without changing the current page of main ram that is active.

 

edit: Also, going back to the v8 vs scanned manual issue: the scanned pdf's state that the page size is 2kbytes, whereas v8 (iirc) simply mention page misses once or twice but never elaborate on the issue or the page size in the jaguar console.

 

 

I believe the docs are wrong on the 2KB page size. The page size is dependent on the RAM chips used.

 

You can imagine the RAM memory as a grid of memory cells. To select a memory cell in a normal DRAM chip is a two step process. First you select the row and then the column. In fast page DRAM, you only have to select the row once when you access multiple columns in the same row. Thats why access in the same page (row) is faster.

 

Now, the Jaguar has 2MByte of ram in four 16-bits wide chips. So each chip has 512KByte (16-bits wide) thus 512*1024/2=262144 16-bit cells. The square root of 262144 = 512 thus there are 512 rows with 512 columns each selecting a 16 bit cell. Thus each page is 512 * 2 byte (16 bits) = 1024 bytes or 1KB per chip. Since there are 4 chips in parallel to give 64-bit wide access, the page size is 4*1KB = 4 KByte

 

Robert

Edited October 2, 2009 by rdemming

[disjaukifa]

As for the 5v flash, Zero, you said the chips are under 10 euros each, that's over $20US today just for the chip -- note that KSkunk was estimating roughly $10US per board, fully populated, using the 3v parts. I think his point stands.

 

Actually they're cheaper than that estimate. It's $6.50 USD per chip if you buy more than 10. That's a pretty good deal!

 

If you're willing to design a new PCB, your game fits in 2 megabytes, you don't need a 32-bit bus, and you don't want the complexity of level converters and regulators, Zero's design looks hard to beat.

 

If you don't use professional assembly, you could make that kind of PCB in a toaster oven for around $10/unit. There's some labor involved in that, but it can't be worse than clipping ROMs off old PCBs.

 

 

- KS

 

How exactly do you build that??? How do you make a PCB??? I'm very curious!

 

-Disjaukifa

[Zerosquare]

When executing code out of main ram (risc code or 68k code), the odds are that any data loaded or moved will be a long way away from the code, thus causing two page misses on every load and every store, and up to three page misses on 68k instructions. In fact the only 68k instructions that won't cause two page misses are ones that only operate on register operands or immediate data.

True, and it's something I never really thought about. Oh well, one more reason not to use the 68K

 

That's a lot of cycles wasted waiting for the memory controller. You could probably get double the performance from the 68k simply by running your code from either cart space or the cache in tom or jerry... assuming the 68k can cope with their "all memory is 32 bit" behaviour.

I'd have to check (I did some testing on this some time ago), but I think you're right, at last for the GPU : I don't think 16-bit accesses work properly, so the 68K would not run. Anyways, if you're going to be limited to 4K or 8K of code, you might as well make that RISC code

 

In fact I've done testing that shows it even runs in the "test" mode of 1 wait state (IIRC), although the OP can't read it at that rate, and other custom chips may also have trouble (I was running 68k code).

There's definitely a pitfall there. SCPCD tried it for the JagCF, and he found there's an intermittent bug in some cases ; I think it involves the blitter, and possibly an arbitration problem when several processors try to access the bus at the same time. You'd have to ask him for details.

 

As for the 5v flash, Zero, you said the chips are under 10 euros each, that's over $20US today just for the chip -- note that KSkunk was estimating roughly $10US per board, fully populated, using the 3v parts. I think his point stands.

You're aware that child labour is illegal, right ?

(j/k, but I would be very interested to know how you could get such cheap prices )

 

My design is still cheaper at higher quantities/larger cart sizes, but Zero is pointing out a better solution for low quantity/low design effort. That's more of what Jag developers need.

I agree with you ; if I were designing something for mass production, I'd definitely choose a 3.3 V Flash too, as they're cheaper and easier to get hold off. For low-volume, it's less clear cut.

 

Nobody has mentioned the lack of EEPROM for save state yet, but if you have a flash chip and you wire it properly, you can use part of the flash for save state.

I'd be a bit wary of using the Flash chip for save states - think of what would happen if there's a bug in the code ! Call me paranoid, but I'd wire it as read-only and add a cheap, dedicated EEPROM chip Edited October 2, 2009 by Zerosquare

[Tyrant]

I believe the docs are wrong on the 2KB page size. The page size is dependent on the RAM chips used.

 

You can imagine the RAM memory as a grid of memory cells. To select a memory cell in a normal DRAM chip is a two step process. First you select the row and then the column. In fast page DRAM, you only have to select the row once when you access multiple columns in the same row. Thats why access in the same page (row) is faster.

 

Now, the Jaguar has 2MByte of ram in four 16-bits wide chips. So each chip has 512KByte (16-bits wide) thus 512*1024/2=262144 16-bit cells. The square root of 262144 = 512 thus there are 512 rows with 512 columns each selecting a 16 bit cell. Thus each page is 512 * 2 byte (16 bits) = 1024 bytes or 1KB per chip. Since there are 4 chips in parallel to give 64-bit wide access, the page size is 4*1KB = 4 KByte

 

Robert

 

Hmm... interesting. I really don't know enough about how ram access works to know if you're right or not, but either way, it's still a fairly small window, given that ALN will pack all the text segments together and all the BSS after it, the odds are that code and data will very rarely, if ever, be on the same page.

[kskunk]

You're aware that child labour is illegal, right ?

(j/k, but I would be very interested to know how you could get such cheap prices )

 

Robot labor is guilt-free! Seriously, automated assembly shops are super-cheap these days.

 

I use Screaming Circuits "Short Run" for assembly. The board I quoted used 10 parts, 5 BOM items. The quote they give is $4/board, but I get 25% off so it's $3. (BTW, you never pay full price at SC -- they give you 10% off on your first order, and you can get more by asking.)

 

You can stay under $10 total by using cheap chips (I think the BOM cost was under $3/board) and by buying really small 2-layer PCBs. You don't need a full height PCB to make a good mechanical connection -- the micro-sized Skunkboard fits snugly in existing shells. I used Sunstone for Skunkboards, and they'll do small nickel-gold finger boards for ~$3.50 qty/100.

 

There are cheaper PCB places around, but the ones I looked at wanted to skimp on the reliability of the nickel-gold plated fingers, or couldn't bevel the finger edges to Atari specs, etc.

 

I'd be a bit wary of using the Flash chip for save states - think of what would happen if there's a bug in the code !

 

Some flash chips have non-volatile lock bits that prevent some or most of the chip from being overwritten. The Skunkboard uses this to prevent accidental overwrite of the boot code.

 

- KS

Edited October 2, 2009 by kskunk

[kskunk]

How exactly do you build that??? How do you make a PCB??? I'm very curious!

 

This is a pretty good review of the ways hobbyists assemble PCBs cheaply:

http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=59

 

- KS

[Zerosquare]

Forgot one thing...

Also, going back to the v8 vs scanned manual issue: the scanned pdf's state that the page size is 2kbytes, whereas v8 (iirc) simply mention page misses once or twice but never elaborate on the issue or the page size in the jaguar console.

It looks like you're absolutely right. I always used v8 as I thought it was the most recent version, but comparing it with the one scanned by Starcat, it's obvious that it's not. For other documents, I used a different set of files as they were cleaner (can't remember who did the scanning), but it appears they're older than Starcat's version.

 

Now I have to read the whole documentation again to see if there are "new" things in it .

Many thanks, Tyrant !

[Tyrant]

Forgot one thing...

Also, going back to the v8 vs scanned manual issue: the scanned pdf's state that the page size is 2kbytes, whereas v8 (iirc) simply mention page misses once or twice but never elaborate on the issue or the page size in the jaguar console.

It looks like you're absolutely right. I always used v8 as I thought it was the most recent version, but comparing it with the one scanned by Starcat, it's obvious that it's not. For other documents, I used a different set of files as they were cleaner (can't remember who did the scanning), but it appears they're older than Starcat's version.

 

Now I have to read the whole documentation again to see if there are "new" things in it .

Many thanks, Tyrant !

 

You're welcome, glad I could be of some help.

 

See, I very rarely get round to actually writing any code, but I do spend a lot of time reading docs and planning code.

[kskunk]

See, I very rarely get round to actually writing any code, but I do spend a lot of time reading docs and planning code.

 

Ha, me too! I have some little kernels written that benchmark and render different things, but no game. Somebody fund me!

 

- KS

[kskunk]

Now I have to read the whole documentation again to see if there are "new" things in it .

Many thanks, Tyrant !

 

Thanks for pointing this out, Tyrant!

 

Jag_v8 was released by John Mathieson. It was likely the final revision of the document authored by the Flare engineering team.

 

The scanned "Software Reference" guide is clearly derived from Jag_v8 with substantial edits.

 

The main differences:

 

The newer document adds a lot of clarifying information and diagrams, which makes it a friendlier reference. Known bugs are also mentioned throughout the relevant sections instead of being bunched up as a 'surprise' at the end as in Jag_v8.

 

The newer document deletes a lot of content from Jag_v8. Specifically, Jag_v8 talks about other applications of the chipset -- for example, other genlock and system clocking options, other Jerry bus width options, other peripheral arrangements (such as early CD, DMA, and paddle memory maps that went unused), and unused features like the PWM DACs. Jag_v8 also contains chip pinouts and detailed hardware signal descriptions with timing diagrams. Clearly none of this information is relevant to Jaguar game developers so there's no reason to have it.

 

I think Jag_v8 has more original information in it, while "Software Reference" is better written but simply rehashes the same details contained in Jag_v8.

 

"Software Reference" is clearly better for beginners, while Jag_v8 is nice for people who want to know every juicy detail.

 

I'm curious to hear what you think after reading them!

 

- KS

Edited October 3, 2009 by kskunk

[ovalbugmann]

Here you go. I've included both the scanned copies from '95, and the "v8" version from '93 released in 2001. I'm convinced that the v8 version is earlier, and thus outdated by the scanned copies, but you're welcome to draw your own conclusions.

 

http://rapidshare.de/files/48454707/MANUAL.zip.html

 

Hope they're helpful to you.

 

I can't download that file after the 90 seconds download ticket wait, I put in the three characters it wants and then it always says; "download session invalid" I've tried it with IE, Opera, Safari, and Firefox and copy/pasting the download link(given after waiting) into a few download manager programs. I can't download the file! - damn Rapidshare sucks!

[Robbbert]

Just tried it now, works fine. Turns out I've already downloaded all this twice before from other places... oh well.

[ovalbugmann]

I still get:

Download-session invalid. Please click here.

 

Possible reasons:

 

* Download-session expired. Direct-links last a few minutes for free users and a few days for premium-users.

* You requested this download-session from a different IP than yours. If you use AOL, try a different browser.

* If nothing helps, getting a premium-account will override the IP-check, which means it will solve this problem.

 

I have only one IP, this error must be because I have dial-up or live in the wrong country - not Germany or some other lameness. Oh, Well.

[Atari_Owl]

And anyways, it's best to copy everything you can into RAM anyways since ROM is much slower in all cases

 

Symmetry of TNG made an interesting test program a few years back, in which he blitted a bitmap several dozen times from cartspace into ram, and then blitted the same image the same number of times from ram to ram. He was using an alpine, and found that actually, the cartspace ram on the alpine was slightly faster than the main systems ram, most likely due to avoiding page misses in main ram. I'm not sure how this compares to cartspace roms, but I would assume its similar.

 

 

Frankly I'd take anything he said with a pinch of salt.

[Zerosquare]

I have only one IP, this error must be because I have dial-up or live in the wrong country - not Germany or some other lameness. Oh, Well.

The same files are available on Starcat's website. On dial-up, however... you can cook and eat a nice dinner before it's finished downloading