Game console as self-sufficient computer

[epsilon537]

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.

[Cyber]

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.

[epsilon537]

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.

.

[SlithyMatt]

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.

[John Chow Seymour]

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.

[SlithyMatt]

If you really wanted to put the Computer back into "Family Computer", you really only have two options, as the RAM issue needs to be addressed:

1. Modify the board to enable more RAM. The standard board has that 2kB from $0000 to $07FF, and then mirrors that three more times. You hook up a daughter board with another 6k of RAM and bodge that in, and you could even implement some banking. This is still a ridiculously small amount of contiguous RAM, and you have to violate the integrity of the board. At that point, you might as well just design a new board around the PPU and APU chips to have a computer that looks and sounds like an NES, and could effectively emulate one.

2. Do it all in the cartridge. You have a lot more wiggle room in the "ROM" section of the memory map, nearly 48k. You could probably take 8-16k of that to make a simple development system, like an in-memory assembler and tile editor. You'd have the rest of the "ROM" and actually make it RAM. You could even make it banked so that you could build program and graphics data at the scale of latter-day NES games, which could be much bigger than 48k, thanks to banked ROMs.

Either way, you then need the ability to connect a keyboard and some mass storage. You could easily make a keyboard connect through a controller port (and Nintendo did, with FamiCom BASIC), but storage is more difficult. Since you probably want to save your programs, you'll need to connect to a tape or disk or something. The easiest thing would be to play a modulated stream through the audio RCA jack and just record that. Problem is, you have no way to load it back to work on it further. Your best option (at least on the exported NES -- this won't work on a Japanese FamiCom) is to use the expansion port on the bottom. It has the CPU data bus connected to it directly, but most of the address bus isn't there. So, you could use it as a parallel port and dump data into a storage device, which could also act as a ROM burner, or at least something that adds ROM images to an SD card that you could pop into a multicart. You could dump assembly source and metadata in there, too. It would... not be fast... but it could work.

The big "but" is that this would not give you the "code and try" immediacy you may be looking for. It would be a process, at best, of turning off the unit, swapping the SD card into a multicart, and swapping that in with the development cart. This is something you could easily do with the C64, or the Apple II or Atari 800, and you could still have all the fun of making a game with a 6502 system, and not go through all that. It also speaks to the "dream" of the X16, which gives you that immediacy along with the speed and resources to make the process as painless as possible.

[TomXP411]

On 5/31/2022 at 6:56 AM, SlithyMatt said:

The big "but" is that this would not give you the "code and try" immediacy you may be looking for. It would be a process, at best, of turning off the unit, swapping the SD card into a multicart, and swapping that in with the development cart. This is something you could easily do with the C64, or the Apple II or Atari 800, and you could still have all the fun of making a game with a 6502 system, and not go through all that. It also speaks to the "dream" of the X16, which gives you that immediacy along with the speed and resources to make the process as painless as possible.

At this point, I'm just thinking "why not add I/O to the cartridge itself?" In theory, one could add a couple of PIO chips and run all the necessary functions from the cartridge. The NES itself would essentially just be a dumb terminal for the cartridge. I could see the cartridge starting up to a BASIC-like console, the user loading a game from disk (or flash storage) into a banked RAM system, then the system swapping out the ROM and basically rebooting directly to a RAM bank, starting the game. 

For development, the game would exit back to the command prompt by switching the bank back to the ROM. 

Of course, this doesn't solve the fact that the NES and similar consoles are terrible for text... but you could put an 80 column VDU on the cartridge, too, because why not? 

I mean, at this point, we're basically just talking about putting a whole computer on a cartridge... but then that really what you'd need to do in order to build a self-hosted system for game console development.

[Cyber]

On 5/31/2022 at 4:56 PM, SlithyMatt said:

The big "but" is that this would not give you the "code and try" immediacy you may be looking for. It would be a process, at best, of turning off the unit, swapping the SD card into a multicart, and swapping that in with the development cart.

I also thought about this hurdle. I understand there will be limitations and compromises should be made. Turning off/on unit between different modes is not a huge deal. Swapping storage media can be avoided by combining everything in one cartridge and adding a physical switch on the cartridge.

On 6/1/2022 at 11:04 PM, TomXP411 said:

I mean, at this point, we're basically just talking about putting a whole computer on a cartridge... but then that really what you'd need to do in order to build a self-hosted system for game console development.

I thoght about this as the most easiest solution. I can put some tiny computer or MCU on the cartridge board, which will run IDE and allow all the development process. Technically this would not be much different from developing on the saparate computer, but it will give some feel of "code and try" immediacy.

When starting this thread I though that some board hacking is unavoidable to achive what I described. But after reading replies I now understand it can all be done in cartridge. It would be very complex cartridge in fact, with lots of RAM, bank switching, keyboard and storage controller, some switches and buttons, etc. But no matter how ugly this cartridge might turn out, I actually like this idea more then modifying the main board. I'm not sure if I'm ready to start this project, but discussing the possibilities is already fun. Thank you, guys! )

[Cyber]

Here is a very close try to what I wanted to see except one big disadvantage: you can not program in this thing. But looking from different standpoint, this is very good looking OS running on NES! Maybe more to come in this project.

[BruceMcF]

A big advantage of doing it all in a cartridge is you have the natural location for all of the I/O parts right there on the cartridge board, on the opposite edge from the cartridge port.

AFAIU, on NES powerup/reset, you'd have:



$0000-$07FF: NESRAM

$2000-$3FFF: PPU I/O ports

$4000-$5FFF: APU/Controller I/O ports

$6000-$7FFF: Work RAM if installed on CART

$8000-$FFF9: Cartridge ROM

$FFFA-$FFFF: NMI/IRQ/RESET vectors

If you have a clever enough banking scheme, you only need one RAM and one FlashROM chip. But "clever" here means setting things up so you can get from the start-up state to the normal memory map with the smallest possible boot-up code. Suppose it's 128KB each:

• 
  The $8000-$FFFF decode circuitry splits between the 16KB HighRAM window in $8000-$BFFF and the 16KB  ROM window in $C000-$FFFF
  


• 
  The bottom half of RAMBank 0 appears in the WRAM space in $6000-$7FFF
  


• 
  The banking latch has its reset pin hooked up, so on powerup/reset, the banking latch has is in its $00 state
  


• 
  The banking latch is: bit0-bit2 = ROM A14-A16; bit3-bit5 = RAM A14-A16, bit7=RAM/ROM, bit
  


• 
  In $00 state, ROMBank 0 is selected in $8000-$BFFF, with Bit7 of the latch selecting between ROM and RAM /OE in that space
  


• 
  In RAMBank $00 state, RAMBank 0 is selected for $8000-$BFFF
  


• 
  With RAM selected in $8000-$BFFF whether or not it's output is enabled, you can have the transition routine at the top of ROMBank 0 which copies itself to the top of RAMBank 0, toggles out the ROM, then calls code in the normal ROM window. Only JMP COLDSTART / ... / COLDSTART: ... / ENDROM is assembled for the ROM appearing at $8000, everything else is assembled for ROM appearing at $C000.
  


• 
  You have eight ROM segments and eight HighRAM segments, 2KB NES RAM and 8KB "LowRAM" that also appears in $8000-$9FFF when RAMBank 0 is selected.
  

While you can mask out RAM when setting ROM (and visa versa): "STA CALLROM : LDA BANK : AND #%1111100 : ORA CALLROM", you can also design code that allocates a ROM bank together with its own dedicated RAM bank, so, eg, "SYSCALL" executing in NESRam or WRAM is: "LDA THISBANK : PHA :  LDA #SYSBANKS : STA THISBANK : STA BANK : JSR + : PLA : STA THISBANK : STA BANK : RTS : + JMP DOSYS,X".