The same and usual C64 guys talking of A8 todays versions

[emkay]

 

But they are here and we are there

 

You, not we

[José Pereira]

 

But they are here and we are there

 

You, not we

 

Are you sure?

I can't believe that you, at least, don't go there in privat just to read and know what it's goin on...

[sack-c0s]

I'm still curious about my question actually - given how flexible the respective cartridge ports are on the A8 and C64 and the price of FPGAs these days you can pretty much cram something approaching an entire computer into the form factor of an 80s cartridge and relegate the C64/A8 itself to ebing a mere keyboard/joystick reader (not far off how starfox worked on the SNES).

 

So how much 'cartridge assistance' do people feel is appropriate before it's no longer 'a stock machine game'?

[flashjazzcat]

I tried to answer that question in post 20 but I assumed (perhaps correctly) that no-one was listening.

Edited September 14, 2011 by flashjazzcat

[sack-c0s]

Sorry about that - it's a good answer, but people trying to perpetuate a war pushed things over to the next page.

 

Quoted to keep it visible

 

I think what people are wondering is where is the line? I know it's going to be blurry at best, but I'm wondering what the consensus is...

I like to define it as "anything which fundamentally alters the character of the machine". Hence I have no problem with banked carts and RAM carts, internal RAM expansions, IDE interfaces, etc, etc. Faster processors, higher resolution graphics and / or greater bit depth, blitters, co-processors, etc, are on the other side of the line. They delegate work away from the CPU and Antic and imbue the machine with capabilities which simply may not have been achievable "back in the day", while hard disks, banked carts and RAM upgrades were relatively common in the machine's heyday.

[José Pereira]

I'm still curious about my question actually - given how flexible the respective cartridge ports are on the A8 and C64 and the price of FPGAs these days you can pretty much cram something approaching an entire computer into the form factor of an 80s cartridge and relegate the C64/A8 itself to ebing a mere keyboard/joystick reader (not far off how starfox worked on the SNES).

 

So how much 'cartridge assistance' do people feel is appropriate before it's no longer 'a stock machine game'?

 

I bought back in time on my oldest Job in Super/Hypermaket an 'out of stock' Megadrive with some games and a Master System. Emulating cart (what a great Afertnoon as I also bought a Game Gear with the T.V. Adapter with some games (sadly the sound was broken)). It was really great Bargains I've got there !...

The games I also bought there were most of them from Master system and they run all on MegaDrive.

It was a cart with a Male and a Female... plugs into Megadrive and on the other side he plugs-in the Master system carts.

 

Would this be the same as those today FPGAs.?

 

And what could we expand the A8 with just a cart? can we, for example have new Gfxs. Modes or it will only turn A8 into a 'Slave Machine'?

That REU cart on C64 what it, exactly expands the C64 stock Machine?

Edited September 14, 2011 by José Pereira

[sack-c0s]

On the FPGA front if you have the lines to the cartridge port the FPGA could see the RAM of the host machine and do whatever you want with it. You could build a new soundchip, graphics hardware... Starfox/starwing on the SNES builds a tilemap from a 3D image the DSP created in its own framebuffer, then copies it back into SNES video memory for display), so you could adapt the technique for the C64/A8 and some kind of basic 3D GPU would be possible.

 

It's just a matter of imagination and time really - even if people think the end result is 'crossing the line' I think it's still a worthwhile and interesting experiment and when I can lay my hands on my FPGA kit I might bring myself up to speed with VHDL and see where it leads.

 

 

Back on the C64 front - the C64 REU is a memory expansion, but rather than banking in memory it uses DMA to copy between the standard 64K of memory and its own, which is at first glance is a pretty naff design as a memory expansion because it's more of a RAM disk than usable memory. I suppose if you wanted to do multitasking it'd be handy for context switching (DMA pages 0 and 1 back and forth to switch tasks), but most people would write it off as not much use.

 

But it has some nifty side effects - you can abuse it as a primitive blitter by making it fill video memory faster than the CPU can, or you can lock it to hammer a single register every cycle (again faster than you could load/store in 6502) and do ticks that you would expect from the copper on the amiga. Or you could hammer the last byte of VIC-RAM to further expand on the border bug to create a bitmapped overscan without using sprites.

[Wrathchild]

With something like the ABBUC/AtariMax USB Cart (using a USB-2-Ethernet adapter) or the new Atari 8-bit Ethernet cart, the TCP/IP stack would be implemented by the A8. By having a cart with an onboard device such as the PIC18FxxJ60 family then that could be taken care of by the device's micro and so 'free-up' the A8 to some extent (would still need to 'marshal' the data to the A8 (possibly through some shared RAM that could be banked in?). Could a SIO-2-Ethernet type of device could also work a dedicated micro?

[Bryan]

I like to define it as "anything which fundamentally alters the character of the machine". Hence I have no problem with banked carts and RAM carts, internal RAM expansions, IDE interfaces, etc, etc. Faster processors, higher resolution graphics and / or greater bit depth, blitters, co-processors, etc, are on the other side of the line. They delegate work away from the CPU and Antic and imbue the machine with capabilities which simply may not have been achievable "back in the day", while hard disks, banked carts and RAM upgrades were relatively common in the machine's heyday.

 

That sounds reasonable. The Atari fell between the Apple model of an open, reconfigurable machine and the Commodore model of a pre-configured box. So, Apple users would probably tell you that any cards and expansions are fair game and Commodore users tend to code for the stock machine. The 800 had (and indeed required) RAM cards in the beginning and the 64K barrier was broken fairly early on by companies like Mosaic and Axlon. I still think its preferable to write for common hardware when possible, though.

 

If you strap a bunch of FPGAs and modern hardware to the machine then eventually you end up relegating the Atari to being either a coprocessor or a mere terminal for another machine. That's something distinct from retrocomputing IMHO.

 

That Pokey conversion emkay posted is awesome, BTW.

[emkay]

And what could we expand the A8 with just a cart? can we, for example have new Gfxs. Modes or it will only turn A8 into a 'Slave Machine'?

 

 

If using an external CPU, you could use that speed to write directly to the GTIA registers, making a full software colour overlay for the 128 colours (OR 256 colours in GTIA mode). Which would result in a real 160x240 256C mode, limited to always one CPU/Antic cycle for all changed registers.It would be fast enough for changing 4 colour registers every 4 colour clocks aswell.

But, we talk of stock machines with the always allowed reachable Memory from it.

 

 

 

That REU cart on C64 what it, exactly expands the C64 stock Machine?

 

It serves like an ultrafast Drive. This would make it possible to handle more graphics content, making it changeable more fluent. 'But more gfx need more speed from the CPU to get coordinated.

The C64 could get a really good looking Dragon's Lair version with it. The candy-colours fit and there is only precalculated content to handle.

 

But, as we may see in Metal Dust, even with a very fast CPU (and up to 16MB direct adressable RAM), it still looks like C64, just more objects got to be moved.

 

Biggest profit by the expansion there is the digital audio....

 

 

http://www.youtube.com/watch?v=Ie79hicxteg

Edited September 14, 2011 by emkay

[analmux]

Sack only tries to project his own thoughts towards me.

 

I think you may have over estimated your importance there - I've been busy coding. You really aren't worth the time and effort to talk to or even worry about.

Why wouldn't it surprise me if R4ngerM4n is the one who gives you an increase of your post scoring.

[popmilo]

I like to define it as "anything which fundamentally alters the character of the machine". Hence I have no problem with banked carts and RAM carts, internal RAM expansions, IDE interfaces, etc, etc. Faster processors, higher resolution graphics and / or greater bit depth, blitters, co-processors, etc, are on the other side of the line. They delegate work away from the CPU and Antic and imbue the machine with capabilities which simply may not have been achievable "back in the day", while hard disks, banked carts and RAM upgrades were relatively common in the machine's heyday.

Agreed 100%

 

Of course you can make miracles with modern fpga-smd-cpu-ram-whatever devices.

 

Chameleon for C64 is one of those:

 

http://www.vesalia.de/e_chameleon.htm

 

 

It is just a "simple" cartridge... But it can work as a stand-alone unit, so it doesn't even need C64

 

ps. It is beautiful device and I would love to have one!

[sack-c0s]

That's a bit pricier than what I had in mind - I was sure you could cut down to the bare essentials and turn out a cartridge at a price that compares favourably to what one would cost back in the day.

[popmilo]

That's a bit pricier than what I had in mind - I was sure you could cut down to the bare essentials and turn out a cartridge at a price that compares favourably to what one would cost back in the day.

Yeah, it is just an example of device that is doing too-much (if it is possible).

 

Simple RAM expansion can be made for C64 also with SRAM and some logic in fpga (even Gal would be enough).

Banking in blocks of external ram + simple dma would be more than enough.

[José Pereira]

And what could we expand the A8 with just a cart? can we, for example have new Gfxs. Modes or it will only turn A8 into a 'Slave Machine'?

 

 

If using an external CPU, you could use that speed to write directly to the GTIA registers, making a full software colour overlay for the 128 colours (OR 256 colours in GTIA mode). Which would result in a real 160x240 256C mode, limited to always one CPU/Antic cycle for all changed registers.It would be fast enough for changing 4 colour registers every 4 colour clocks aswell.

But, we talk of stock machines with the always allowed reachable Memory from it.

 

 

For example, on A8 something like REU, a 'simple just Cartridge' or what are you talking, It could have:

1.)- More than the 4PMs.?

2.)- Hi-Resolution PMs.?

3.)- Hi-Resolution movement?

4.)- Hi-Resolution colour?

5.)- Real Char-Mode type of C64/A8 PF2&PF3 with more than just 2colourmap colours?

6.)- Real Multicolour Char-Mode where each char have it's own 3colours on a common Backgr. colour?

7.)- Use the 128or256 colours at any place in a real Bitmap 'Loadsa colours' mode?

8.)- Have more than 256colours when these are 8bits 256colours?

(Off course, it would also have a Sound enhancement)

 

But with all this what have Atari 8bit stock Machine 'to do with'?

All these on Cart (like REU on C64) would in communication with what GTIA and not ANTIC? It would be an ANTIC substitute?

It could be more 'stock/A8 thing' then VBXE?

 

Could this Cart be something like the Expansion of A8 but compatible with older Machines and something like Atari didn't and would be an inside Expansion?

(something like, if the 130XE would have this new things inside, have backs compability instead of having only the 128Kb. Memory expansion...)

 

 

Thanks.

José Pereira.

Edited September 14, 2011 by José Pereira

[sack-c0s]

if by 'a simple cartridge' you mean something on par with the REU, then it wouldn't give you any extra sprites from a hardware point of view, but it would be able to hammer the existing hardware faster than a straight load/store in 6502 would. It would possibly allow you to do more with the existing sprites and colours.

[emkay]

With an external CPU you could simply import and show pictures to the A8 , looking like those (no changing of the hardware inside the computer , and no interlace or else....) , and you could easily animate them in 50 or 60 Hz ....

 

 

 

 

[popmilo]

...

If using an external CPU, you could use that speed to write directly to the GTIA registers, making a full software colour overlay for the 128 colours (OR 256 colours in GTIA mode). Which would result in a real 160x240 256C mode, limited to always one CPU/Antic cycle for all changed registers.It would be fast enough for changing 4 colour registers every 4 colour clocks aswell.

How would you make that 256c in 160 resolution ?

What GTIA regs would it use ?

 

As I know - one cycle - one memory location changed.

On A8 it is 2 color cycles for 1 cpu cycle.

So external DMA could change one memory location every 2 color pixels...

 

But, I don't like those - kernel like methods - too much cpu time gets wasted.

 

Better to use extra ram for large lookup-tables, and precalculated graphics (3d, 2d rotation, shifted sprites, rle-encoded sprites etc.).

[sack-c0s]

it would be an interesting experiment to backport the copper from the Amiga to the A8 and see what kind of a boost you get from it

[Rybags]

You can't use a cartridge to allow read/write to internal RAM.

 

And we've discussed already the pitfalls of attempting it with PBI attached devices.

 

Additional to that, you can't hit registers at more than 1 per cycle. Before VBXE came along, there was a project under way to have a device which could do fast stores to GTIA colour registers, but it never went anywhere.

[sack-c0s]

really? bugger - I assumed that you could do that on the A8 and the C64....

 

might be worth a try on the C64 though - as much as I love the thing not being able to STA WSYNC is a bugger

[Rybags]

I'd suspect there's similar limitations on the C64. You can't hit registers at > CPU speed. Sure, the bus runs at 2 MHz but VIC uses most of those cycles for hidden DMA and Refresh and the allocation is highly variable.

 

We do have Project Veronica. A high speed CPU on cart means the main CPU could just spend the entire display time doing colour/register changes while the cart-based one does most of the gruntwork of rendering and moving stuff around.

[frogstar_robot]

I'm still curious about my question actually - given how flexible the respective cartridge ports are on the A8 and C64 and the price of FPGAs these days you can pretty much cram something approaching an entire computer into the form factor of an 80s cartridge and relegate the C64/A8 itself to ebing a mere keyboard/joystick reader (not far off how starfox worked on the SNES).

 

So how much 'cartridge assistance' do people feel is appropriate before it's no longer 'a stock machine game'?

 

There are also the mappers and miscellaneous assist hardware in NES and SNES carts. We have another thread hereabouts discussing overclocking a part inside a Star Fox cart to make it run faster. Pitfall II on the VCS has some assist hardware to reduce the CPU burden of the music. I can't see a hard bright line on this sort of thing. Like FJC said, banked rom and ram don't change the essential character of the machine and were common back in the day. If the C64 crowd insists on "rules" for this sort of thing then carts with banked RAM/ROM surely don't break them.

 

The NES and SNES commonly added things akin to auxiliary vector units and 3D processors but the console still did the bulk of the work. Now we have auxillary ARM processors doing the bulk of graphics rendering on the VCS but the VCS still spits the data to the screen and runs much of the game logic; the displays are still bounded by the TIA's capabilities but far more CPU time is available to eke out every last bit of what it can do. The upcoming 7800 expansion is more or less on the level of the mild assist hardware and additional memory included in NES carts and seems mostly a way of not putting most of that hardware in many carts though it does an additional Yamaha sound chip. But then the 7800's design implicitly assumed that additional sound hardware in the carts would be common with the low cost chip intended for this role most of the time getting axed.

 

Then we have things like VBXE which upgrade the video capabilities of the A8 but leave the stock video capabilities intact.

 

The final level we've seen in "2600 Adapters" for various consoles. In that the cart port is just a power supply and AV pass-through with no real symbiosis between the two platforms.

 

To me, the thing that most defines the capabilities of the old platforms is the audio and video chips with the CPU and memory setting additional limits on what those chips can be made to do. More RAM and even CPU simply allow those chipsets to be exploited to the fullest. Things like the VBXE push us more in the direction of the "A8GS": a few people get to experience what might have been.

[sack-c0s]

I'd suspect there's similar limitations on the C64. You can't hit registers at > CPU speed. Sure, the bus runs at 2 MHz but VIC uses most of those cycles for hidden DMA and Refresh and the allocation is highly variable.

 

True, but the two things that come to mind are

 

1) you can't hit at CPU speed from the CPU - you'd lose time from the LDA/STA pairs, so it would still be an improvement

2) if a write needs to be synchronised (e.g hitting a register at a specific time synced to the beam) there's a big CPU drag in synchronising, waiting and then performing the write.

 

so there's still pretty good gains to be had even with those limitations. It must be possible to do though, as the REU manages it.

[ijor]

1) you can't hit at CPU speed from the CPU - you'd lose time from the LDA/STA pairs, so it would still be an improvement

2) if a write needs to be synchronised (e.g hitting a register at a specific time synced to the beam) there's a big CPU drag in synchronising, waiting and then performing the write.

so there's still pretty good gains to be had even with those limitations. It must be possible to do though, as the REU manages it.

 

You certainly could build such a device that would write to GTIA (or other chips) at full CPU speed. That is, one write per PHI2 cycle. The question is if this would be worth. How much this would be cheaper and simpler than more advanced devices.

 

If you could do that on cartridge, then it might be worth. But you can't. I don't think even the PBI would be enough here. Something like this would require removing say, GTIA, inserting a custom board in GTIA's socket, and put GTIA in the board. When you go that far, you start asking yourself if it's not worth to take the extra step and do something like VBXE.