Game console as self-sufficient computer

Cyber · Post by **Cyber** » Tue May 17, 2022 11:07 am

On 5/17/2022 at 1:46 AM, Tatwi said:

https://www.retroreversing.com/famicom-nes-development-kit/

Plenty of data to refine. Some of these are new for me. I'll give my feedback later. Thank you!

Also I am interested to learn about similar solutions for Ataris, Segas and other retro game consoles.

John Chow Seymour · Post by **John Chow Seymour** » Tue May 17, 2022 11:38 am

On 5/17/2022 at 2:39 AM, TomXP411 said:

It's theoretically possible - you can write a game cartridge that acts like a text UI, load a machine monitor and maybe even a BASIC interpreter on it. That's just all software. The only hard part would be getting keyboard input. You'd either have to put some sort of PIO chip, use the expansion connector (on an NES that has one), or hack a keyboard into one of the controller ports (probably with an Arduino.)

I've also thought of doing this, but it would be pretty low resolution and probably look like a VIC-20 in terms of text size.

I'm not sure what the BASIC interpreter would be for - I don't know of any NES games that run on a layer of BASIC. Then again, I suppose there are cases where you could use BASIC as a tool to create resources (sprites, music?) for the eventual ML code to access.

Having an ML interpreter right on an NES reminds me of using my PE6502 kit computer. It boots into WozMon, which is sort of a bare-minimum OS, but also has an ML assembler onboard called Krusader (link to the manual). Sine the 2A03 is 6502-based it may be possible to get Krusader onto our hypothetical keyboard-enabled NES.

Development in 6502 assembly on a 6502 for that same 6502 is, in my opinion, a fun challenge. You need memory space for the source code, for the assembled version of the code, for any data the assembled version draws on (strings, etc.) and for Krusader itself, all in a single 64k address space; and it's up to the programmer to manage all that manually. Working on the PE6502, I found myself coding low-level utilities that let me do simple things like "create a new string and save it at a given memory address". Once that tool was tested and working, I could delete the source code for it to free up space but continue to use the assembled tool as I continued to work on the project.

These additional constraints are not ideal, but that's kind of the point of taking on the challenge of developing on-system. And yes, we could get around the space constraints with RAM expansions (on our hypothetical NES, not on the PE6502). I'm not sure what @Cyber is up to, but good luck! It sounds like fun!

TomXP411 · Post by **TomXP411** » Tue May 17, 2022 7:57 pm

On 5/17/2022 at 4:38 AM, John Chow Seymour said:

I'm not sure what the BASIC interpreter would be for - I don't know of any NES games that run on a layer of BASIC.

It's the simplest way to build tooling, such as asset editors (tiles, sprites, levels, music), although it's not strictly necessary.

Ultimately, all that is necessary is a BIOS with text and file I/O, plus a 5 command monitor program: Examine Memory, Modify Memory, Execute, Save, and Load. Everything else stems from that.

Cyber · Post by **Cyber** » Fri May 20, 2022 5:34 am

On 5/17/2022 at 2:38 PM, John Chow Seymour said:

Development in 6502 assembly on a 6502 for that same 6502 is, in my opinion, a fun challenge.

I understand there is some constraints and limitations. But generally speakaing some 8-bit micros already delivered this experience out of the box. For example C128D provided not only assembly environment, but also a sprite editor out of the box. June from Nybbles and Bytes channel showed how one can code a game in 6502 on 6502 for this same 6502. I agree it is a "fun challenge" by modern standards. But in the 80's for most programmers this was just normal, regular and actually the only way to develop in assembly. So a developer from 80's may not call this a "fun challenge", but rather "just doing my job". Of course some companies had more powerful equipment for developing purposes, but it is rather a specialized case.

Am I wrong here? Or am I missing a point?

SlithyMatt · Post by **SlithyMatt** » Fri May 20, 2022 11:39 pm

On 5/20/2022 at 1:34 AM, Cyber said:

Am I wrong here?

Not entirely. A key thing to remember is that while the development platform was likely 8-bit, it was not generally on the same home computer platform but on a workstation PC. You wouldn't code a C64 game on an actual C64, but you might on a late-model PET, a CP/M machine or even an IBM PC.

hardrockhero · Post by **hardrockhero** » Sat May 21, 2022 5:03 pm

So funny story i bought the new atari vcs console. And i was a little underwhelmed with it as a gaming console its OS left alot to be desired... but it runs Linux very well. I actually currently work from home on my atari. Hahaha

BruceMcF · Post by **BruceMcF** » Sun May 22, 2022 1:22 am

On 5/17/2022 at 7:38 AM, John Chow Seymour said:

...

Having an ML interpreter right on an NES reminds me of using my PE6502 kit computer. It boots into WozMon, which is sort of a bare-minimum OS, but also has an ML assembler onboard called Krusader (link to the manual). Sine the 2A03 is 6502-based it may be possible to get Krusader onto our hypothetical keyboard-enabled NES. ...

Nick Gammon's G-Pascal for Ben Eater's 6502 breadboard computer, based on G-Pascal for the C64 (if I understand correctly, because the C64 version was the one where he could find his old source code) is similar, with a bytecode "tiny" Pascal compiler (integers and chars, no sets or floats, but IIUC integers are 24 bit), assembler, simple line editor and command line shell, along with I/O code for connecting a serial UART via the 65C22 VIA: G-Pascal on Github, G-Pascal on Nick Gammon's site, 6502.org discusssion.

epsilon537 · Post by **epsilon537** » Sun May 22, 2022 8:43 am

On 5/22/2022 at 3:22 AM, BruceMcF said:

Nick Gammon's G-Pascal for Ben Eater's 6502 breadboard computer, based on G-Pascal for the C64 (if I understand correctly, because the C64 version was the one where he could find his old source code) is similar, with a bytecode "tiny" Pascal compiler (integers and chars, no sets or floats, but IIUC integers are 24 bit), assembler, simple line editor and command line shell, along with I/O code for connecting a serial UART via the 65C22 VIA: G-Pascal on Github, G-Pascal on Nick Gammon's site, 6502.org discusssion.

Another option is to combine an interpreter with inline assembly. An interpreter is much easier to bring up on a constrained device than a compiler. Here's uLisp for instance: http://www.ulisp.com/

On virtually all 8-bit home computer systems, that interpreter was BASIC obviously. I assume it was always and only BASIC because of the easy learning curve. But there do exist other options besides BASIC.

BruceMcF · Post by **BruceMcF** » Sun May 22, 2022 1:32 pm

On 5/22/2022 at 4:43 AM, epsilon537 said:

Another option is to combine an interpreter with inline assembly. An interpreter is much easier to bring up on a constrained device than a compiler. Here's uLisp for instance: http://www.ulisp.com/

Yes, an advantage of G-Pascal is that Nick Gammon has already written it, and it was originally written to run in ROM on a 6502 board in the 70's, then ported to the Apple II and C64, so porting it to another 8bit system is a lot less challenging than porting a system originally designed for a larger system.

And a tiny Pascal compiler for a bytecode VM fits a lot more easily in a ROM of an 8bit system than a native code compiler for a more complex language. Intrinsic to the design of the original Pascal was a syntax that supports single pass compilation.

Cyber · Post by **Cyber** » Fri May 27, 2022 5:55 am

On 5/21/2022 at 2:39 AM, SlithyMatt said:

Not entirely. A key thing to remember is that while the development platform was likely 8-bit, it was not generally on the same home computer platform but on a workstation PC. You wouldn't code a C64 game on an actual C64, but you might on a late-model PET, a CP/M machine or even an IBM PC.

Ok, I must admit I have a lack of knowledge about this. I'll try to paraphrase myself. I'm trying to talk about home experience. My point is that somebody, who had a C64 back in the 80's was able to code a game (or any other software) in assembly targeted for this same computer. I never had a C64, so I can't know for sure. But I judge from what I read in articles and from what I see in videos today: people could and people did code in assembly on 8 bit micros for this same 8 bit micros at home. They had only this one machine. Their resulting software would be much less advanced than commercial software - I understand this.