Nosty's Tomek Cartridge for 8-bit Atari - great!

[xxl]

In my opinion a cartridge is the best and natural way for Atari upgrade. TOMEK-8 with PIC24 microcolntroller for Atari can be like Super-FX for SNES (http://en.wikipedia.org/wiki/Super_FX).

 

or SuperCharger for game Assault Force 3d

 

http://www.atarimania.com/game-atari-400-800-xl-xe-assault-force-3-d_348.html

 

[Stormtrooper of Death]

It seems that many good expansion cards are being invented for our beloved Atari 8bit. Sadly, not many software is written. If the producer/inventor of a new expansion chip./card would also ask a chinese factory to make new Atari 8bit computers based on the original concept of 1983, but this time with the new add-on card included, and sell it worldwide for 39 euros at ToysR Us or so, then it can make an impact at the current world of 2012. Otherwise, the new invention , will go into oblivion with the rest of forgotten expansion cards that are not used by many Atari 8bit people.

 

Simply speaking: Money is what we need, a chinese factory that makes 100.000 of these new Atari 8bit machines... then it can work.

[Jetboot Jack]

MaPa & Stormtrooper,

 

I beg to differ this is not another unsupported A8 expansion (and to be honest if you have bought, installed and are using a VBXE or whatever, you're probably very happy with it, supported by others or not).

 

The reason this is 1000% better than any other upgrade in my opinion though is super obvious, it requires no MODIFICATION of the 8bit to work, so ANYONE can use it.

 

PLUS if I want to release a game using it, I can incorporate that in the cart I sell you - so you get my game all souped up w/o needing to install any upgrade - genius!

 

sTeVE

Edited September 5, 2012 by Jetboot Jack

[jakeLearns]

Honestly I love both this cartridge and the VBXE.

 

However, going back to a previous thought of adding this type of functionality to the emulator - that made me think, it's not the emulated cartridge co-processor that I want to talk with first - but the emulator itself.

 

To me it's the same type of logic, if you can have a real atari - presumably taking input from the joystick, and manipulating a game, a game powered by this co-processor on the cart - and then you emulate that experience. Who says that co-processor even has to be PIC - why not be the native processor on your PC?

 

And once you open up this - frankly the first thing I want - is not some super cpu powered game, I want something much simpler. I want to be able to configure the emulator itself.

 

Say you just set aside a certain spot in memory - that on a real atari does nothing, but the emulator is peeking into that memory area - and if you configure it a certain way you are signalling to the emulator that you want to set it's configuration. Now I can tell the emulator, on the emulated R: handler send the message "Connect 9600" - or leave that message off. I can configure the emulator to work the way I want, without having to tell the user tweak all these settings for this particular program.

 

Just a thought - I'm sure the emulator writers have enough to do without taking my suggestions But, since the thread did talk about emulation...got me to thinking along these lines.

[+JAC!]

JAC!: you already have all the gear it needs to write something, right? that vbxe equipped machine you won at sillyventure is still getting dust in your storage i suppose, and we're always looking forward for anyone willing to write something neat

In fact I still have no answer from Electron an how to get the connector to the monitor right (I though it was plain VGA but it isn't). And writing a demo for VBXE - hmm, I somehow miss the limitation to be honest. That's what is normally driving me the most - doing something that "cannot" be done. Regarding nosty's cardridge I have to say, that this idea of taking advantage of the "excessive" MHz of the co-pro to do "reverse bit banging" via $d500 as loophole is really neat. If we can get this so cheap that it pays out for cartridge games, it'd be great. I also see the similarity to the POKEY on a card. Though adding XYZ MHz CPU power in parallel again is about to be cheating somehow. Yeah, limits - you know :-)

[xxl]

Though adding XYZ MHz CPU power in parallel again is about to be cheating somehow. Yeah, limits - you know :-)

 

it is possible to do VBXE CORE with CPU that works in parallel with 6502

[José Pereira]

Would it be possible with this tomek cart get cycles/cpu to re-use, have more than hardware pmgs and pfs colours on the same scanline? And does it also get beter results on the charmodes 'badlines'?

If it's possible then it would be only on static screens or also on horizontal, vertical or gways scrolling?

 

If not this, is it possible to build a cart that does this?

[xxl]

you can use Antic $02 or $04 char mode with 256 chars and 1 bit attributes so 9bit per char...

[José Pereira]

Xxl how you get 256 chars on gr.0 and gr.12 or gr.13 on the same scanline(s)?

[candle]

JAC: this is standard RGB connector you can find on commodore 1084, not VGA, and as for limitations - try to use it, and you'll find them pretty fast it all about thinking out of the box and finding use for blitter to do the thing for you with very few instructions it can process - ie see titus the fox level scroll and how it build the screen as it goes using minimum resources reuqired

[xxl]

my english is too poor to explain but maybe someone translate.

 

przestrzen adresowa TOMKA8 podzielona jest na cztery obszary, dwa odczytu i dwa zapisu. TOMEK8 nie wie dokladnie z ktorego rejestru odbedzie sie odczyt albo do ktorego zapis wie tylko z ktorego to bedzie obszaru. obszar odczytu dla Antica ma np 48 bajtow dlatego poniewaz Antic tyle danych moze pobierac w linii, TOMEK8 wie, ze Antic chce czytac dane z jego obszatu odczytu i podklada dane z pamieci obrazu. ANTIC moze czytac z tego obszaru wszystko: Display List, dane znakow, dane obrazu albo np. duszki...

256 znakow w zestawie to 8 bitow na znak. zestaw znakow (256 znakow $800 bajtow) musi znajdowac sie w pamieci TOMKA8 (CHBASE ustawiony na $D4), pamiec ekranu z ktorej pobierany bedzie numer znaku do wyswietlenia rowniez w pamieci TOMKA, natomiast pamiec ekranu dla ANTICa moze byc w pamieci Atari i sluzy za pamiec atrybutow tu ustawiamy tylko atrybuty (bit7) natomiast ekran wypelniamy jednym znakiem ktory przy odczycie wskaze na odczyt z obszaru odczytu ANTICA w przestrzeni TOMKA. sytuacja wyglada nastepujaco: ANTIC pobiera znak z pamieci ekranu (w Atari) czyta dane znaku z pamieci TOMKA, ktory podklada dane znaku wedlug pamieci ekranu w swojej przestrzeni, Antic te dane interpretuje dodajac atrybut i wyswietla. Jet to mozliwe dlatego, ze TOMEK podlozy dane ANTICowi wedlug kolejnosci - wie dokladnie kiedy bedzie czytanie znaku/linii dlatego podczas wyswietlania, cpu nie moze czytac z rejestrow odczytu ANTICA. wyswietlanie 256 niezaleznych znakow nie zabiera czasu procesora.

[nosty]

Xxl how you get 256 chars on gr.0 and gr.12 or gr.13 on the same scanline(s)?

 

As XXL wrote: this is a trick

 

Imagine you use Display List like this:

 

dl

dta $70,$70,$70

dta $42,a($D500)

dta $42,a($D500)

...

dta $42,a($D500)

dta $41,a(dl)

 

so Antic reads screen's chars from $D5xx page

 

And you must set charset: CHBAS = $D4, so Antic reads chars definitions from 32 do 63 from $D5xx page.

 

But real screen definition and chars definitions (for 128 or 256 chars) are stored in coprocessor internal memory.

 

It's all. Microcolntroller on cartiridge can prepare for Antic ANY char's definition.

 

How it works? Antic read first char from first line memory ($D500) : 32. So it reads char (no 32) definition (8 bytes) from addresses $D500..D507. Next, Antic reads second char from $D501. And it is 32 again So Antic reads char's definition from addresses $D500..D507 again. BUT NOW... coprocessor prepares for Antic different char definition according to screen definition in its internal RAM memory.

 

It sounds crazy but it really works I tested it.

[candle]

nosty, how about definitions 00-1F? (and 80-9F)

these should be read from locations d400-d4ff

 

i'll answer myself

char that is on "screen" memory is always 0x20, so you just redefine it as you go

Edited September 5, 2012 by candle

[+JAC!]

>Would it be possible with this tomek cart get cycles/cpu to re-use, have more than hardware pmgs and pfs colours on the same scanline.

In fact it does the same as the good old Pitfall II cartridge for the VCS. It simulates memory that automatically changes it's content with the required timing.

In the VCS cart this is used to make a kernel like:

LDA #a sta pf0 lda #b sta pf1 lda #c sta pf2

read different values a,b,c every time. So you had self-modifying code in a ROM.

After all, this is only simulating memory, hence it will not directly give you cycles.

 

>And does it also get beter results on the charmodes 'badlines'?

You could do what I did in rotator in Silly things. I.e. force ANTIC to not trigger bad lines and the use the card to redefine the chars on the fly.

Then you can get any mode without bad lines (CPU will be rather busy though keeping ANTIC from triggering them).

 

>If it's possible then it would be only on static screens or also on horizontal, vertical or gways scrolling

Since the whole thing is like a "sliding window" at $d500 which traverses the internal RAM of the card

you can scroll just like you scroll with the LMS instruction in the normal display list. Just change the starting

address from which the internal RAM is displayed. Fine scrolling can still be done by ANTIC.

Edited September 6, 2012 by JAC!

[xxl]

or...

you can also draw in TOMEK8 memory in graphical mode and force it to send data to Antic in text mode, which gives 40x24 (960) different fonts plus attributes memory

 

or...

you can fill all screen defined by 240 tiles 16x16 (2 bytes x 16 bytes) in ... 1000 6502 cycles :-)

[Chilly Willy]

I don't remember reading this, but can it handle color modes as well as B&W? Mode 14 instead of mode 15, let's say. That would be probably what most games would use... imagine a demo like the video, but with color instead of B&W. There's enough space at $D500 for two lines, meaning it COULD handle some of those "blended" special modes for more simulated colors. I guess it all depends on what the PIC is programmed to handle.

[nosty]

i'll answer myself

char that is on "screen" memory is always 0x20, so you just redefine it as you go

 

Exactly. 0x20 or 0xA0 for fifth color

 

I don't remember reading this, but can it handle color modes as well as B&W? Mode 14 instead of mode 15, let's say. That would be probably what most games would use... imagine a demo like the video, but with color instead of B&W.

 

Of course TOMEK will support color modes in near future. The hi-res mode was a first try only.

[candle]

in monochrome mode there is no sense in using "char" mode to simulate char mode, the same result you can have with graphics mode, but without penalty of "bad lines"

in colour mode, you would loose that fifth colour

[slampam]

1) Would this cart idea work with a 70's or 80's microcontroller, like a PIC1650, or is that too slow?

2) Is there anything about the Atari 5200 that would exclude a PIC24 from being used with its memory layout?

 

32 Sprites would be wild!

[Rybags]

5200 already has the Ultimate SD cart from Atarimax http://atarimax.com/5200sd/documentation/index.html

 

In theory it should already be able to do something like this one does - although I don't think the cart has /RW line (?) which makes interfacing a bit harder.

[GameEngine]

Was any NES emulator ported to PIC24?

[nosty]

Was any NES emulator ported to PIC24?

 

As I know - no And NES has too many colors for Atari...

But if you want you can try to port Game Boy emulator

[1NG]

The concept of the tomek card is cool. I do a game for 130xe with or without VBXE. I still have no VBXE but Altirra works well emulating it. If it emulates tomek too, then a version for it is also thinkable.

I like the Idea of a tomek chip inside a cartridge. I agree to some point that original hardware is the one and only true platform. And if there are to many extensions available then nobody will be able to play a game on his hardware. Unfortunatly it is not possible to support all hardware for graphics, sound and i/o with some kind of drivers. There is not enough memory and cpu power to do that (Even no Driver API). Every piece in a game is usually optimized for the used hardware. And if drivers would exist, then the speed of the hardware would differ.

So? Tomek is OK for me, because it can be used as a separate hardware. VBXE is still a good hardware though. My problem with VBXE is mainly the poor availibility and that only one core is available which supports functionality of a (very fast) blitter. (BTW: How is a core written?)

 

My other idea before reading about tomek was a complete hardware for graphics, sound and i/o. Programmable core, sprites, extended memory, digitized sound and enhanced i/o (ethernet, midi, hdmi). This would be a new defined platform which takes standard hardware to a new defined level. games can support that easier. But that would end up like an Amiga with better graphics and sound but poor cpu.

I like the old games and would like to preserve the style of them. Using sio2sd is no problem for most people (atari computer stays untouched). Enhanced Memory as no problem too. Enhanced graphics is different and should not be too much. Enhanced sound is good as well, but same problem. Enhanced i/o like ethernet and hdmi ist fantastic in my opinion since this would give better multi player games in old and fun style. And playing multiplayer games is a lot of extra fun! Having hdmi solves the problem for the actual monitors to have a good picture without washed out colors, flickering, wrong aspect ratio and other effects.

As a programmer I can not make a game that needs 100 people with different tasks and tools. Atari is a good platform to do a lot of things by one person or a small team.

 

Not an easy task to set the Atari++ platform right. My thought is: Enhanced graphics? yes, but not to much. Simple digitized sound? yes. And the previously mentioned ethernet port and hdmi out. That all together in a cartridge would be perfect!

[nosty]

Just proof-of-concept...

[Mclaneinc]

Wow Nosty, that is SWEEEEEET...

 

Any chance the proof of concept will go beyond that. obviously thats just a bare bones demo to show the cart but it would be lovely to see the game mechanics implemented to see what the cart can do with a fully fledged game.

 

Only take you a couple of days