codewar65

The 65816 was an abomination IMHO. If it had full dedicated address pins, I might say otherwise. lol

Esperanto? https://sites.google.com/site/windowskeyboards/Home

I never got out of retro computing. I've been in since it was new and exciting.

Looking at the page source, looks like it was written with Notepad and not FrontPage. Good work old man!

It's hard to moderate an open forum with limited active community. I think going newsletter only might be their current plan. That way, they can cherry pick issues for the next issue, while avoiding troll flames.

Same. A ran a four node T.A.G. BBS out of Barre, VT back in the early 90's. On FidoNet and DoorNet fbackbones. Fun times.

Waterloo on the SuperPET. *warm fuzzies* BASIC, Pascal, and FORTRAN. They never offered APL at my college. I did take up COBOL at university and ended up do stupid Y2K stuff at a job decades later...

Apple's garage computer was a piece of wizardry. Woz made an amazing machine with what he had. Jobs made the world eat it. I was picked out to help my high school select a system for our first computer lab back in the early 80's (I was one of a few kids in school who already owned a Home Computer). Tandy vs Apple vs Commodore. I picked the Pet as it was a serious machine (i've seen all three in action and specs); the school (as did many) ate the Apple. Because of educational discounts to indoctrinate the youth to continue to eat the Apple. We still see the effects to this day. Apple = Eye candy. Get a real system. The 6809 was a wonderful processor that I have worked with. With the (indirectly with the SuperPet SP9000) and with coding the chip directly. I wish it took off. Really.

If the 6809 sold at the same price or less than a 6502, would Sweet16 even exist?

mmmmmm... doughnuts... *drools*

The 6809 was a wonderful CPU. As much as the 6502 is. I know more 6502 and the 6809, but the 6809 was: New Old Stock.

Gathering resources, equipment, and foo to start breadboarding my own 8bit here. A VERA would solve a ton of issues. Circuitry to drive video can be bigger than a main system using available off the shelf.

Personally, I think the team should stick with just phase-1. Get one flawless solid product out the door, in kit form or finished, then expand from there. Many things learned in going phase-1 will alter future branches. The X8 sounds like a whole different product. It'd be like asking the C=64 user base if they would be interested in a C=32. Why?

'Dumb' terminal is a term, for a terminal. Some weren't so dumb. I am just looking to offload cycles onto another processor with dedicated capabilities, like how C64's 'talked' to disc drives with their own 6502s.

I'm old school and love old dumb terminals! I was thinking of building a 6502 based VT100 terminal VERA. haha I was actually thinking of grabbing Ben's kit as well, but want to get a better breadboard setup. And writing my own terminal, I could 'add' my own special codes to redefine the character glyphs, play sound, sprites, etc. Even upload 65c02 code via ANSI to run as a background process and report back on a separate VIA port with results.

This thread should be in the non-cx16 retro channel, but: I've been thinking of tinkering with two 65c02s to build a breadboard machine. The first would be the main system, the secondary would handle screen and keyboard (ala terminal). They'd communicate through 6522's. The secondary would just take VT52 or VT100 style codes for video as input and send keyboard / escape code response codes back as output. That would free up the main CPU to run full bore, while the terminal CPU could buffer and state-machine the ANSI codes and handle keyboard voodoo while in vblank/hblank when driving video.

What if the network card worked like old school CBM smart peripherals? Put the brains on the card / device. Open a channel to it, send commands, write data, read results, close the channel, etc. It shouldn't matter if it uses Hayes modem or raw socket io protocol, as long the 'thing' buffers IO properly. It could handle any protocol (internally translated on the device or natively implemented on the CX16).

Never the less, I would have loved to have seen a 832 and a real CBM using it. I left the Commodore scene when the Amigas started to pop up and went full IBM. I never cared for the GUI OSs until OS/2 Warp and then Win XP.

I would have pushed the 65c832 to production, and developed a new 80 column C64/128 style machine with a CBM PETSCII Unix style OS while trying to keep it usable for the masses with a BASIC built in, etc. Many of us back then liked the platform as it was CLI and basically a gaming console with the ability to develop your own stuff.

Not for me either. Too many moving parts. You only need one versatile sound option. One versatile video option. One versatile game controller option. etc. Bolting on kitchen sinks will confuse and fragment developers, force users to buy controllers and cards for every scenario.

We'd need to be able to be able to pass parameters to a new process, pipe input and output, and spawn/fork processes. Clearly, outside of the scope of a Commodore style BASIC, but maybe handled to some extent by an extended BASIC add-on. Maybe disk commands could be prefixed with a '>' (i.e.: >dir, >app24.prg, etc), parameters captured by system variables AN (number of args), and AV$() (values), a simple batch scripting interface that returns control to the script loaded into high banked RAM once a process is finished, or something.

I played a ton of Master of Orion and MOO2. Same with other 4X games (Master of Magic, Warcraft, Warcraft 2, Dune II, Dune 2000, Command & Conquer, Colonization, Civ I and up). Great genre if done right. A MOO style game with trade (5X - ... +Exchange) and non hostile NPC races built in would be cool as well. Kind of like the old Starflight game or Trade Wars 2002 BBS game.

Reminds me of the old IBM Reference docs that were distributed on CDROM back in the day, for mainframe development, DB2/UDB, etc. Also a request, make the left/right frames resizable by dragging a handle between them.

Two X16's and a KVM?

Basically the machine does not load Linux or other OS and then load the emulator, but the OS *is* the emulator, coded in assembly, and optimized to 'bare metal'.