Jump to content

Game console as self-sufficient computer


Recommended Posts

  • Administrators

When you develop a game (or any other software) for some system you usually have two ways to do it.
1. Develop it on target system itself;
2. Develop (and compile) it on external system, and use target system only to run the result.

Some systems allow you to do development in any way, but when developing for game consoles you usually have to use external system to do all the development.

Have you seen examples, when somebody modified some game system changing it into a self-sufficient computer, so you can develop on it directly?

I would be most interested in Atari, NES/Famicon, Sega, but any other game consoles are also of interest.

Link to comment
Share on other sites

Just saw this yesterday: 

And I've seen many people turn the OG XBox into a Windows XP desktop. I don't know how well they work as development systems, but they both have USB and ethernet connectivity, so you have a lot of expandability options.

  • Thanks 1
Link to comment
Share on other sites

I haven't watched the video above yet, but the last time I read about this, converting your PS2 to a Linux box meant that it could never play PS2 games again.
You couldn't really develop "for the console, on that console" in that case, then.
But, I guess you could develop for PS2 Linux on PS2 Linux!

Link to comment
Share on other sites

On 5/15/2022 at 6:47 PM, John Chow Seymour said:

converting your PS2 to a Linux box meant that it could never play PS2 games again.

This isn't a conversion. It is just an alternate boot. You can go right back to playing PS2 games if you reboot with a game disc. The guy in the video goes a step further to make it work for different monitors and be able to boot from an internal SSD.

  • Thanks 1
Link to comment
Share on other sites

The Colour Maximite systems are effectively this concept. One system that is both the programming and execution platform. They also boot to directly to a unified programming and execution environment. Bonus: Said environment uses the BASIC language at roughly the speed of native C64 machine language.

Really bummed out that wasn't able to get either.

Link to comment
Share on other sites

  • Super Administrators

The Atari 2600 VCS actually had a BASIC cartridge and keyboard. It was kind of horrible to use, though, since the VCS has a super-low resolution. 

There was also a keyboard + BASIC interpreter for the NES, called Family BASIC. https://en.wikipedia.org/wiki/Family_BASIC 

The Playstation 3 could boot to Linux in the first two major versions of the firmware, but Sony removed that ability later. Still, while it was available, it was possible to develop and play PS games in Linux on the console. 

 

Link to comment
Share on other sites

I know you can run Linux on an original XBox, maybe later units as well, I don't follow any of that anymore. If you Google XBox Linux, you'll find all you need.

A buddy of mine did that several years ago, he was running some form of servers on them, I can't recall now. Still, it worked, and it worked well at mimicking a basic desktop for the time.

On the Atari front, forgive me my memory isn't what it used to be, but I do recall the VCS being used as basically just a video source, like @TomXP411 said, there was an external cart or something that did everything else. I wish I could remember where I was reading about that. It wasn't all that long ago...

Stupid memory. 😛

Link to comment
Share on other sites

  • Administrators

Thank you for your thoughts. But that is quiet not what I meant. I know about Maximite (I even have two of them). I also know about Famicom Basic. I think I did not asked my question clear enough.

I want to be able to use NES like say C64 or VIC-20. On Commodore machines I can talk to bare metal anyway I want. I also can write assembly, and develop a program that talks to kernal and to hardware. I want to have same experience on NES. I want to monitor RAM,  talk to PPU, write assembly directly on hardware itself. I understand that NES was not designed to allow this. I'm not even sure it is possible to modify NES to be able to do this. FPGA solution might be more realistic.

I know I can get what I want on a PC. There are great environments to write and debug NES programs. But I am curious if anybody built system with such environment as a stand alone self-sufficient solution.

Link to comment
Share on other sites

  • Super Administrators
On 5/16/2022 at 12:51 PM, Cyber said:

Thank you for your thoughts. But that is quiet not what I meant. I know about Maximite (I even have two of them). I also know about Famicom Basic. I think I did not asked my question clear enough.

I want to be able to use NES like say C64 or VIC-20. On Commodore machines I can talk to bare metal anyway I want. I also can write assembly, and develop a program that talks to kernal and to hardware. I want to have same experience on NES. I want to monitor RAM,  talk to PPU, write assembly directly on hardware itself. I understand that NES was not designed to allow this. I'm not even sure it is possible to modify NES to be able to do this. FPGA solution might be more realistic.

I know I can get what I want on a PC. There are great environments to write and debug NES programs. But I am curious if anybody built system with such environment as a stand alone self-sufficient solution.

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.

 

  • Thanks 1
Link to comment
Share on other sites

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!

  • Like 2
Link to comment
Share on other sites

  • Super Administrators
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. 

 

  • Like 2
Link to comment
Share on other sites

  • Administrators
Posted (edited)
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?

Edited by Cyber
typo: C64D -> C128D
Link to comment
Share on other sites

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.

  • Thanks 1
Link to comment
Share on other sites

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

  • Like 2
Link to comment
Share on other sites

Posted (edited)
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.

Edited by BruceMcF
  • Like 1
Link to comment
Share on other sites

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.

 

Link to comment
Share on other sites

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.

  • Like 1
Link to comment
Share on other sites

  • Administrators
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.

Link to comment
Share on other sites

On 5/27/2022 at 7:55 AM, Cyber said:

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.

Yes, that was how most people worked on a C64. The same computer was both the host and the target. The result was not less advanced than commercial software. On the contrary. I was in the C64 demoscene in the late 80's early 90's, and the demos the scene was outputting at that time was consistently more advanced than 95% of the games out there. The whole point of demos was to push the limit of the machine. Most games on the other hand were on some kind of budget (money and time) and were being developed with many different home computer targets in mind, so they weren't explicitly pushing the limits of the C64.

SlithyMatt's comment about cross development being the norm may have been true for the bigger studios, but there was a lot of indie development going on, e.g. sceners making games and tools, and that was almost always done on a single C64, the machine being both the development host and the target.

  • Thanks 1
Link to comment
Share on other sites

  • Administrators
On 5/27/2022 at 12:52 PM, epsilon537 said:

Yes, that was how most people worked on a C64. The same computer was both the host and the target. [cut]

[cut ] . . . that was almost always done on a single C64, the machine being both the development host and the target.

Yes, this is what I was talking about.

I wish to know whether there is a possibility to implement same experience on popular game consoles like NES, Atari 2600, etc. Or rather I wish to know whether somebody already went through all the trouble of implementing such working environment.

How I imagine this to be done is one need to take original hardware (or reimplemetation of it). Then hack into it adding i/o controllers for keyboard, storage, etc. And create some OS for development environment. Resulting with a look and feel similar to C64 with its BASIC and MON. Full BASIC is not critical here. Any rudimentary peeking, poking. moning, asming is fine. It is a thing for fun after all.

Not that there is any usefulness in this. It is very geeky thing to want.

Link to comment
Share on other sites

On 5/27/2022 at 12:36 PM, Cyber said:

Yes, this is what I was talking about.

I wish to know whether there is a possibility to implement same experience on popular game consoles like NES, Atari 2600, etc. Or rather I wish to know whether somebody already went through all the trouble of implementing such working environment.

How I imagine this to be done is one need to take original hardware (or reimplemetation of it). Then hack into it adding i/o controllers for keyboard, storage, etc. And create some OS for development environment. Resulting with a look and feel similar to C64 with its BASIC and MON. Full BASIC is not critical here. Any rudimentary peeking, poking. moning, asming is fine. It is a thing for fun after all.

Not that there is any usefulness in this. It is very geeky thing to want.

Yes, it should be possible.The exact solution will depend a lot on the console chosen, so if you're going to pursue this, I think you should pick one, say NES, and focus on that.

The NES is designed as a console, not a general purpose home computer, so you're going to have to add the missing pieces to turn it into a general purpose home computer. It's going to need at least a keyboard, a filesystem, and some working memory. The more you add, the less NES it becomes, however, so you're going to have to strike a balance.

I think an FPGA that presents itself to the NES as a cartridge should do the trick. The FPGA has internal memory, can implement a PS/2 interface for a keyboard, an interface for a microSD card, and a serial port for file transfer to/from the device (so you don't always have to swap SD cards in and out).

It sounds like a perfect retro computing project! A nice mix of hardware, software and reverse engineering.

.

  • Like 2
Link to comment
Share on other sites

On 5/27/2022 at 6:36 AM, Cyber said:

I wish to know whether there is a possibility to implement same experience on popular game consoles like NES, Atari 2600, etc.

Not really. And to clarify, I was indeed talking about professional development being on other systems. Obviously, homebrew for the C64 was almost entirely on the unit itself until the advent of PC-based emulators like VICE. But this was because the C64 was a proper computer, if a really small one that wasn't good for much besides games. But it was at least good for SOMETHING besides games. Most 8-bit consoles can really do NOTHING other than play games. If you ever used the Atari 2600 BASIC cartridge, you'll know what I mean. With only 128 bytes of RAM, it's impossible to write code, much less run a compiler or assembler. There was BASIC for the FamiCom back in Japan, but again it was a really simplified thing, and not like the real home computer experience. You only have 2kB of RAM, so you still don't really have enough memory to work on code or run an assembler. Once we get to the 16-bit era, things turn around. The SNES has 128k of RAM, and I bet you could make that into a fairly serviceable computer that could at least do some real programming.

  • Like 3
  • Thanks 1
Link to comment
Share on other sites

Posted (edited)
On 5/27/2022 at 8:45 AM, epsilon537 said:

The NES is designed as a console, not a general purpose home computer, so you're going to have to add the missing pieces to turn it into a general purpose home computer.  It's going to need at least a keyboard, a filesystem, and some working memory.

Don't forget, in addition to the physical keyboard, you'll also need all the 'soft' components: the NES has no character ROM and no concept of a text interface, so your first task after getting that keyboard going would be to draw yourself a font (or steal one) and work out a system for placing characters into both screen memory and file memory, handling line breaks, handling backsapce, etc.  With the NES's PPU being optimized for sprite tiles rather than characters, it'll be an uphill battle. 

That's not to say it wouldn't be a fun, geeky thing to do, as several of you have said.

Edited by John Chow Seymour
  • Like 3
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...

Important Information

Please review our Terms of Use