The Worlds Smallest Atari 8-Bit?

[+MrFish]

17 minutes ago, mytek said:

Yeah he only posted 85 times total since joining AA in 2011, and then stopped. Although I see that he was last on here April of this year.

 

His work on the Compact 5200 was absolutely beautiful and done with great precision. By the end of that thread he had created a fantastic portable gaming system, and then disappeared. I wonder what happened?

 

Yeah, he built 5200 controllers for it too.

 

Ben Heck's portable was pretty cool too. Although I'm much less interested in handhelds than something that can be plugged into a monitor/television.

 

[+mytek]

8 hours ago, MrFish said:

Ben Heck's portable was pretty cool too.

Just don't open it up and look at the PCB . It was done in typical Ben Heck 'gotta get it done' fashion. Total spaghetti wiring, amazing that he was even able to make it work.

 

[+MrFish]

4 minutes ago, mytek said:

Just don't open it up and look at the PCB . It was done in typical Ben Heck 'gotta get it done' fashion. Total spaghetti wiring, amazing that he even was able to make it work.

I mean, he made the whole thing in 3 weeks; what can you expect. I would like to see him do something more polished though.

 

[Tezz]

1 hour ago, mytek said:

Thanks .

 

I use SIPs and SOIC-16 resistor packages to get rid of a lot of the individual resistors that Atari seemed so fond of using (those were different times). Also my glue logic is simpler because of using SRAM instead of DRAM. And in this particular unit, I also got rid of a lot of configuration jumpers and/or switches by using the TK-II I/O to fill in for those functions. So selection of a given language/game slot in the ROM is all handled on the keyboard, as well as choosing bank select modes for the XRAM and enable/disable for the VGATE chip. I also greatly simplified both audio and video driver circuits by going with an entirely different route than what they did (their circuit was overly complicated in some regards). And lastly I have access to better chips then what was available BITD.

 

I'd love to have your updated design in the same form factor as the original 800XL board as a drop in replacement. I did read the other day that someone had recently remade some 800XL boards based on the original schematics but your updated design without all those original shortcomings would be more desirable.

[Gavin1968]

5 hours ago, mytek said:

Perhaps you two can discuss the possibility of you becoming a distributor, if he's open to that.

Not really interested in that, I find the quality of the things I build far better so I would only want to make my own. Thats a bummer would really love to make these. Thanks.

Gavin

 

[+mytek]

6 hours ago, Tezz said:

I'd love to have your updated design in the same form factor as the original 800XL board as a drop in replacement. I did read the other day that someone had recently remade some 800XL boards based on the original schematics but your updated design without all those original shortcomings would be more desirable.

When I post the schematics, anyone can use them to design a new board.

 

For an 800XL just add the cart and PBI ports, which are pretty straight forward to implement. I based the ROM on an XEGS, which allows for both Basic and the OS to reside in a single chip, and gives you an additional 8K slot for a 2nd language or a game. This got doubled up, so that there are four 8K slots, and the possibility of 2 different OSs, all selectable from the keyboard. No reason this can't be carried over into a new design as well (I'll be posting the custom TK-II firmware). There is also 576K of RAM, with 64K of that as base RAM, and 512K extended. The TK-II also selects the two banking schemes (576K Rambo or 256K CompyShop --- individual Antic/CPU access). The design is a hybrid of Hias's and tf_hh's ideas.

 

The extra real estate on an 800XL footprint would allow you to go back to all thru-hole parts, as well as provide a direct plug-in option for a U1MB (to replace the ROM and RAM). And of course Fuji-Net could also be built-in as well. Lots of possibilities.

 

[+gnusto]

6 hours ago, ijor said:

You can have exact transistor level and bus timing accuracy, if you insist, but I don't think that it matters, and certainly that doesn't make the difference between being or not emulation.

 

My point is that you don't have to worry about it at all with the original chips. Although they certainly come with other considerations - sometimes hard to find, slow, bulky.

 

Not trying to start any kind of contentious discussion. I appreciate the effort that goes into hardware mimicry via FPGA (simulation? since you seem to dislike emulation). I get your point that it doesn't matter as long as it is accurate. Maybe there have been updates recently, but when I was using the MiSTer more a while back for Atari emulation it was of note that there were definite inaccuracies, for instance acid800 failed in some cases. I believe the author of the 800 core is even around AtariAge, he would probably know!

 

I still use the MiSTer for some stuff, but since it got hooked up to our TV I haven't been using it for Atari 800, so maybe I'm not current.

[Daedalus2097]

On 6/21/2020 at 4:13 AM, gnusto said:

 

Not trying to start any kind of contentious discussion. I appreciate the effort that goes into hardware mimicry via FPGA (simulation? since you seem to dislike emulation).

"Emulation" for some reason seems to be considered a dirty word by some users of FPGA-based hardware. I think it must stem from a desire to differentiate an FPGA solution from software emulation such as Altirra. But emulation has a broader meaning than just an application that mimics another system. It can be hardware or software. Hardware emulators are used all the time in industry as part of the development process, and even FPGA manufacturers produce and market FPGAs for the express purpose of emulation. So, emulation isn't necessarily a bad thing, once the prejudice that is often associated with the term is ignored.

Edited June 23, 2020 by Daedalus2097

[jamm]

I can understand why people don't like the term "emulation" used when describing FPGA-based solutions.  It's not only not technically correct, it gives the wrong impression of what's happening.  Yes, you could use "emulation" in a broader sense, but we usually don't. 

You wouldn't say AMD processors "emulate" the Intel x86 instruction set.

 

[+DrVenkman]

5 minutes ago, jamm said:

You wouldn't say AMD processors "emulate" the Intel x86 instruction set.

Nor do we say Intel processors “emulate” the AMD64(*) instructions either. ? 

 

(*) Aka, x86-64, first defined by AMD in 2000. 

[ivop]

Indeed, they both reimplemented the others' instruction set in silicon, emulating the other. Only if they copied the relevant parts of eachother die, then it would not be emulating

 

IMHO the only difference between Altirra and an FPGA implementation is the source language and the way the compiled result is executed. You could say Altirra is software emulation, and FPGA is hardware emulation. Or would Altirra suddenly stop being an emulator if it (minus GUI) was run through a C++ to VHDL converter and run on an FPGA chip instead of a CPU?

 

Only non-emulated Pokey, etc..., could be created if @Curt Vendel releases the die files (which I think he has?), although I believe he's not sure if they are ectually the same that were fabricated. So there might be bugs? And after that you have to find a small factory or university that can still manufacture NMOS wafers and put them in a DIP40 package. And pay for it

 

[Keatah]

4 hours ago, Daedalus2097 said:

"Emulation" for some reason seems to be considered a dirty word by some users of FPGA-based hardware. I think it must stem from a desire to differentiate an FPGA solution from software emulation such as Altirra. But emulation has a broader meaning than just an application that mimics another system. It can be hardware or software. Hardware emulators are used all the time in industry as part of the development process, and even FPGA manufacturers produce and market FPGAs for the express purpose of emulation. So, emulation isn't necessarily a bad thing, once the prejudice that is often associated with the term is ignored.

I think "emulation" became a dirty word because of early attempts not having had time to be polished and evolve to a high standard. Early software emulators were buggy, didn't have output that looked like CRT displays, didn't run all carts/games, and stuttered and lagged. It's like that with most things.

 

Early emulation (in general) was developed on much slower processors like 486 and Pentium 1 machines. These processors would hiccup and cause jitters and stutters every time the OS interrupted them. Not so on modern i7 machines. 60fps is maintained very consistently.

 

Early emulation hadn't had time to go through the thousands of iterations to knock out bugs and incompatibilities. Amazing that a bad rap from 15 - 20 years ago still haunts today..

 

Emulators can take some time and configuring. That's not for everyone. And that's ok.

 

But the biggest jab is the widespread misconception that FPGA is a direct duplication of a console/computer in hardware. And that nothing can be more accurate than the the original or a direct copy of the original. In reality FPGA creations of classic gaming hardware are all based on interpretation and reverse-engineering.

 

And I would even argue that software emulation has evolved to become more accurate than FGPA. Of course that's on a case-by-case, system-by-system, basis.

 

 

[foft]

How about we talk about @mytek's cool project?

[+DrVenkman]

Of course, the great thing about @mytek‘s project (this one, and the 1088XEL/XLD before it) is that it’s not emulating anything.  

[ijor]

2 hours ago, ivop said:

IMHO the only difference between Altirra and an FPGA implementation is the source language and the way the compiled result is executed. You could say Altirra is software emulation, and FPGA is hardware emulation. Or would Altirra suddenly stop being an emulator if it (minus GUI) was run through a C++ to VHDL converter and run on an FPGA chip instead of a CPU?

 

IMHO there is a fundamental difference that is not directly tied to the source language. An emulator executes sequentially, while a FPGA core executes in parallel. And that won't change if you if you perform a C++ to VHDL conversion or a simulation of the FPGA core on a computer. Emulators don't emulate every single cycle because it wouldn't be efficient.

 

This doesn't mean, of course, that one is better than the other. But it means that it would be very difficult for an emulator to be cycle accurate when connected externally. An emulator would have a hard time to reproduce sound, let alone video, with cycle accuracy and without lag. Simulating a SIO port (again, with cycle accuracy) to connect to a real Atari drive would even more difficult because the communication is bidirectional and here the latency is very relevant. Or even worse, try connecting an emulator to a real PBI device.

 

On the other hand, an emulator can do lots of things that a FPGA core can't do, at least not without lot of pain. Such as pausing, loading and restoring state, etc.

Edited June 23, 2020 by ijor

[ijor]

31 minutes ago, Keatah said:

But the biggest jab is the widespread misconception that FPGA is a direct duplication of a console/computer in hardware. And that nothing can be more accurate than the the original or a direct copy of the original. In reality FPGA creations of classic gaming hardware are all based on interpretation and reverse-engineering.

Of course there is always a level of reverse engineering. But many FPGA cores are based on original sources. E.g, the original Atari TIA schematics are available since long ago.

Quote

And I would even argue that software emulation has evolved to become more accurate than FGPA. Of course that's on a case-by-case, system-by-system, basis.

I agree. On most cases emulators are actually more accurate because they are more mature. Also many FPGA developers don't target perfect accuracy.

[Mr Robot]

29 minutes ago, DrVenkman said:

Of course, the great thing about @mytek‘s project (this one, and the 1088XEL/XLD before it) is that it’s not emulating anything.  

It's emulating an Atari keyboard?

[jamm]

4 minutes ago, Mr Robot said:

It's emulating an Atari keyboard?

It's emulating my childhood Atari dreams?

[Keatah]

3 hours ago, ivop said:

Only non-emulated Pokey, etc..., could be created if @Curt Vendel releases the die files (which I think he has?), although I believe he's not sure if they are ectually the same that were fabricated. So there might be bugs? And after that you have to find a small factory or university that can still manufacture NMOS wafers and put them in a DIP40 package. And pay for it

 

I know that the C64 has a replacement part or two built from CPLD/FPGA. Aside from logic level translation and bitstream flashrom there'd be little if anything else required.

 

So why not make all the hard-to-find custom chips that way? It sounds like it would be cheaper. And it's a proven method. Like a PokeyONE. But a full Pokey and not just enough to get by.

 

I say that's going to be the future of projects like this. These custom chips won't be available forever and we will need replacements.

 

Either that or if and when printing NMOS at home becomes a thing.. mmm..

Edited June 23, 2020 by Keatah

[+DrVenkman]

15 minutes ago, Mr Robot said:

It's emulating an Atari keyboard?

[+mytek]

1 hour ago, foft said:

How about we talk about @mytek's cool project?

Nice try and i appreciate that ? .

 

So let's do that...

 

50 minutes ago, Mr Robot said:

It's emulating an Atari keyboard?

Yes in a sense it is, but I'd rather call it a keyboard translator .

 

Its also acting as the system controller via key presses that activate, select, or disable certain key features of the system.

 

Presently I'm away from my shop for a couple of days, so I've been taking the time to re-code the TK-II firmware for this unique system. The version of code coming out of this firmware rewrite will only be usable in the 576NUC+.

 

So here's my first stab at the hot key sequences and what they will do.

 

CTRL+ALT+V will enable/disable the VGATE chip (non-volatile)

CTRL+ALT+X will toggle between 256K CompyShop or 576K Rambo XRAM modes (non-volatile)

 

And then we get into Power Control + ROM Bank Select since the 64K x 8 ROM can hold four 8K languages or games, and two OSs.

 

 

Note: If the Power is already ON when pressing ALT+1-5, then a brief power cycle will be issued after the new selection has been made, thus rebooting into the new setup.

 

Should be very easy to use .

 

The function keys will be defined the same as the AKI mode in the last TK-II version release, and the special U1MB related functions will be unchanged (just in case someone decides to install a U1MB).

 

F1 = HELP

F2 = START

F3 = SELECT

F4 = OPTION

F5 = RESET

F6&F8 = no current assignment

F9 = CF Refresh (U1MB)

F10 = HELP

F11 = Launch CF LOADER (U1MB)

F12 = Launch SETUP (U1MB)

 

[Mr Robot]

17 minutes ago, mytek said:

So here's my first stab at the hot key sequences and what they will do.

 

Move Alt+5 to Alt+1 and shuffle all the others down so Alt+1 is on Alt+0 is off. On with BASIC all languages disabled is probably going to be the default option for most games.

 

 

F9,F11,F12... What U1MB? What CF?

[+DrVenkman]

13 minutes ago, Mr Robot said:

F9,F11,F12... What U1MB? What CF?

37 minutes ago, mytek said:

The function keys will be defined the same as the AKI mode in the last TK-II version release, and the special U1MB related functions will be unchanged (just in case someone decides to install a U1MB).

 

 

What we have here is a failure to communicate.

[+mytek]

53 minutes ago, Mr Robot said:

Move Alt+5 to Alt+1 and shuffle all the others down so Alt+1 is on Alt+0 is off. On with BASIC all languages disabled is probably going to be the default option for most games.

Will do ? .

 

--------------

 

Yep not that I would recommend it, but it is conceivable that someone, somewhere will be implementing this board in some way that isn't part of the original plan, hence the reason I will leave the U1MB special function keys as they have been in all the current versions of the TK-II. I got lots of other keys to choose from when coupled with ALT which is not a standard Atari key.

 

[Mr Robot]

So that still leaves the CF refresh which needs a side2? which is impossible without a cart port... unless XEL-CFIII is coming to a NUC+ near you soon?