This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

FDS Version of Family BASIC Video

FDS Version of Family BASIC Video
by on (#66620)
Someone sent me a link to this video, which is apparently a Game Doctor disk (for the FDS) of Family BASIC:

http://www.youtube.com/watch?v=dxk9m8xbXiU

Please don't e-mail him! I sent a letter to the uploader of the video, and I don't want to flood his mailbox with questions about this to scare him away. I will directly report what happens, but in the meanwhile, I'm wondering if anybody else has ever seen this.

I'm curious if the Game Doctor disk will allow saving BASIC programmes to disk or if it is identical to the cart.

Beyond that, it is an interesting curiosity to find out how the GD port maps the normal FDS RAM to the Family BASIC v3 expansion RAM and how the code of the conversion looks when compared to the ROM from the FB cartridge.

This could all prove very interesting in making both disk or cartridge versions of Family BASIC programmes and turning cart games into FDS disk games or even Doctor Disk games.

yes, I know that some of you think this is all pointless, but it is important: It would make it easy to write simple games and distribute them, as well as create interesting hacks or improvements of FDS titles, and possibly provide further insight into the FDS and mapper conversion.

I could name a score of reasons that stuff like this is important, beyond my strange FDS fetish. It would also be neat to write Family BASIC programmes and save them to disk, as that alone would make it an easy-peasy step towards creating a compiler to convert the code into ROM format.

The FB v3 cart is also battery-backed, and I wonder if the Doctor Disk port makes use of the FDS writing feature to auto-save the address range used for programmes. of course, it could simply be a direct ROM conversion and do naught more than the normal release, but it is worth investigating.

As I said, just using it to learn how the Doctor Disk mapper conversions work would be a blessing.

-Xious
Re: FDS Version of Family BASIC Video
by on (#66660)
Quote:
I'm curious if the Game Doctor disk will allow saving BASIC programmes to disk or if it is identical to the cart.
Of course not, you'd have to hack the game to provide raw FDS read/write functions. Family Basic is just a NROM game which the Game Doctor treats as such.

Quote:
Beyond that, it is an interesting curiosity to find out how the GD port maps the normal FDS RAM to the Family BASIC v3 expansion RAM and how the code of the conversion looks when compared to the ROM from the FB cartridge.

Huh? The Family Basic RAM is exactly the same as other cart WRAM (though I think it's 2KiB). Basically all the Game Doctor does is map a few registers into unused space ($42xx-45xx depending on unit) and takes $8000-FFFF for its game. Everything else gets passed through including FDS adapter RAM at $6000-7FFF serving as the WRAM.

Quote:
This could all prove very interesting in making both disk or cartridge versions of Family BASIC programmes and turning cart games into FDS disk games or even Doctor Disk games.

Noooooot reaaaaaallyyyy.... You're thinking too far into it XD You can't easily make your own self-contained games like *snap*. You'd have to hack Family BASIC and link it to your game. Even then you'd have a very limited and poorly performing game... If you want to develop using the FC for the development environment, it'd definitely be better to start from scratch.

Quote:
yes, I know that some of you think this is all pointless, but it is important: It would make it easy to write simple games and distribute them, as well as create interesting hacks or improvements of FDS titles, and possibly provide further insight into the FDS and mapper conversion.
How would BASIC help you hack FDS games or RE FDS/mapper code? There are already disk editors (with disassembler) as well as character editors for FDS by the Japanese company I2.

Quote:
The FB v3 cart is also battery-backed, and I wonder if the Doctor Disk port makes use of the FDS writing feature to auto-save the address range used for programmes.

Everything is lost once you power off. FC copiers don't retain their saves at power off unless they have been modified to do so.

Quote:
As I said, just using it to learn how the Doctor Disk mapper conversions work would be a blessing.

You mean just put NROM, CNROM UOROM & GNROM on disk? It's very simple, just compare the disk image to the ROM, I figured it out before I could program a "Hello World"... Don't expect it to be easy to hack MMC1/MMC3 etc to Game Doctors though, that requires extensive reverse engineering of the game program and Doctor hardware. Not only do you have to write code to remap mapper writes to corresponding Doctor registers but you have to figure out how to stop the game and upload tons of CHR data to CHRRAM without breaking the program sync. IRQ effects will have to be removed or significantly hacked too. CHR-ROM bankswitching animation will also have to be removed unless you target your hack specifically for TGD6.
Back in the day I think they used a hardware in-circuit-emulator for the hacking. These days it's best to use a software emulator with debugger of course.
Re: FDS Version of Family BASIC Video
by on (#66676)
kyuusaku wrote:
Quote:
I'm curious if the Game Doctor disk will allow saving BASIC programmes to disk or if it is identical to the cart.
Of course not, you'd have to hack the game to provide raw FDS read/write functions. Family Basic is just a NROM game which the Game Doctor treats as such.

Quote:
Beyond that, it is an interesting curiosity to find out how the GD port maps the normal FDS RAM to the Family BASIC v3 expansion RAM and how the code of the conversion looks when compared to the ROM from the FB cartridge.

Huh? The Family Basic RAM is exactly the same as other cart WRAM (though I think it's 2KiB). Basically all the Game Doctor does is map a few registers into unused space ($42xx-45xx depending on unit) and takes $8000-FFFF for its game. Everything else gets passed through including FDS adapter RAM at $6000-7FFF serving as the WRAM.

Quote:
This could all prove very interesting in making both disk or cartridge versions of Family BASIC programmes and turning cart games into FDS disk games or even Doctor Disk games.

Noooooot reaaaaaallyyyy.... You're thinking too far into it XD You can't easily make your own self-contained games like *snap*. You'd have to hack Family BASIC and link it to your game. Even then you'd have a very limited and poorly performing game... If you want to develop using the FC for the development environment, it'd definitely be better to start from scratch.

Quote:
yes, I know that some of you think this is all pointless, but it is important: It would make it easy to write simple games and distribute them, as well as create interesting hacks or improvements of FDS titles, and possibly provide further insight into the FDS and mapper conversion.
How would BASIC help you hack FDS games or RE FDS/mapper code? There are already disk editors (with disassembler) as well as character editors for FDS by the Japanese company I2.

Quote:
The FB v3 cart is also battery-backed, and I wonder if the Doctor Disk port makes use of the FDS writing feature to auto-save the address range used for programmes.

Everything is lost once you power off. FC copiers don't retain their saves at power off unless they have been modified to do so.

Quote:
As I said, just using it to learn how the Doctor Disk mapper conversions work would be a blessing.

You mean just put NROM, CNROM UOROM & GNROM on disk? It's very simple, just compare the disk image to the ROM, I figured it out before I could program a "Hello World"... Don't expect it to be easy to hack MMC1/MMC3 etc to Game Doctors though, that requires extensive reverse engineering of the game program and Doctor hardware. Not only do you have to write code to remap mapper writes to corresponding Doctor registers but you have to figure out how to stop the game and upload tons of CHR data to CHRRAM without breaking the program sync. IRQ effects will have to be removed or significantly hacked too. CHR-ROM bankswitching animation will also have to be removed unless you target your hack specifically for TGD6.
Back in the day I think they used a hardware in-circuit-emulator for the hacking. These days it's best to use a software emulator with debugger of course.


Jeepers, I hate responding to threaded quotes in BBCode.

Well, without holding it i your hands, it's impossible to know if the ability to save to the disk has already been implemented by whomever converted it.

Beyond that, at least with a disk version of Family BAISC it is possible to have the FDS RAM-Adapter connected to the FC during operation.

I'm certainly not considering writing amazing, graphical games with it I think it is a useful tool for conversions of existing BASIC programmes, at the least, and I was going to write some TBAs or convert some stuff from old mags to the FC for distribution. Honestly I'd like to convert some old mag-based TBAs to FB and find a way to convert them to FDS (self-bootstrapping) or UNROM or something like that, even if it's for my own enjoyment of playing them.

Having access o the FDS at all would make it possible to create a writing routine, and thus being able to do more interesting things with the software. I may, at some point, even pay somebody to translate one of those overpriced FB guidebooks into English in order to get a better idea of its capabilities and FC-specific instruction set.

I don't know how much effort Hudson put into V3, but it was supposed to be something special and maybe it can live up tot hat potential in the right hands

I don't have high hopes for this, but I think it would be a fun toy for tinkering and having it in disk form would certainly be a great step closer to making a hack of FB that can write to disk, rather than cassette tapes..

Do you have any reference material on ROM to FDS and ROM to Doctor Game conversion? I haven't noticed this kind of reference anywhere on-line, but I suppose that it's possible that could have missed it on ToToTek or somewhere

Learning how to convert MMC1-MMC3 and VRCx ROMs first requires figuring out how the GD hardware conversions work at all, and how they reroute instructions via their custom mapper emulators.

It's not for everyone, but I find it amusing and it's a break from the soldering iron...and sanity as well, i guess, from your perspective.

If you have any docs or refs to converting ROMs to the FDS, send'em my way, along with the FDS decompiling utilities.

-X
Re: FDS Version of Family BASIC Video
by on (#66682)
Quote:
Well, without holding it i your hands, it's impossible to know if the ability to save to the disk has already been implemented by whomever converted it.

But there's an extraordinarily high probability that it wasn't hacked to load/save to the disk. If you think so you're dreaming XD

Quote:
Beyond that, at least with a disk version of Family BAISC it is possible to have the FDS RAM-Adapter connected to the FC during operation.

Of course it is. It would be worth hacking Family BASIC to not even need the Game Doctor since you wouldn't need to rewrite the disk functions and more people would be able to use it. (Maybe PowerPak users too.)

Quote:
I'm certainly not considering writing amazing, graphical games with it I think it is a useful tool for conversions of existing BASIC programmes, at the least, and I was going to write some TBAs or convert some stuff from old mags to the FC for distribution. Honestly I'd like to convert some old mag-based TBAs to FB and find a way to convert them to FDS (self-bootstrapping) or UNROM or something like that, even if it's for my own enjoyment of playing them.

The first step would be hacking Family BASIC to a normal FDS game, not too difficult, not too easy since everything will have to be relocated. If you keep it as a Game Doctor game, I don't think you can switch to the BIOS for disk routines. Definitely best to port it to FDS. I'm sure during the process you could strip a lot of silly content out too giving more program space or space for a CHR editor.

Quote:
Do you have any reference material on ROM to FDS and ROM to Doctor Game conversion? I haven't noticed this kind of reference anywhere on-line, but I suppose that it's possible that could have missed it on ToToTek or somewhere

Nope. It doesn't exist online, but thankfully it's not hard to figure out. Mapper hacking however is very complicated since the hardware isn't accurately documented at all (just a few mapper 6,17 documents) and of course you have to be very familiar with NES programming. I've occasionally worked on reverse engineering FC copiers since 2003, I can definitely say it's not easy.

Quote:
Learning how to convert MMC1-MMC3 and VRCx ROMs first requires figuring out how the GD hardware conversions work at all, and how they reroute instructions via their custom mapper emulators.

How it works is simple:

- There are 6 mapper modes:
-CNROM (NROM) compatibility
-GNROM compatibility
-UOROM compatibility
-special extended CNROM mode
-GD4M mode (special CNROM mode in a 4x8K register file)
-TGD6 mode (4M mode with extended CHR RAM in 8x1K register file)

-There is a file in the FDS disk loaded before the game files that is treated as a header. The header contains configuration data (written to configuration registers).

-Usually old mapper hacks set the mode to UOROM.

-There is another file loaded before the game called the "trainer". This file is the mapper emulation code and it gets loaded into WRAM.

-The game gets loaded into RAM, the hardware is switched out of "BIOS" mode into "game" mode then the game is started.

-Games are hacked so that when a game for example writes to a bankswitch register eg STA $8000 the code gets changed to JSR TRAINER_8000_WRITE (a function in the trainer) which then decodes the mapper write into discrete Doctor register writes.

That's all the easy part, the hard part is making sure all the time spent in trainer code (especially since a large portion of the screen has to be blanked for CHR bankswitch emulation) doesn't break the game.

by on (#66690)
It just occurred to me: It is also possible to update the FDS BIOS ROM to include Family BASIC, so that BASIC loads instantly instead of the normal 'insert disk' animation.

I don't know that this would be any better than having it on disk, except that you could potentially do more with BASIC in ROM than on disk.

I know that somebody put out a utility to save BASIC programmes to disk, but I have very little in the way of information on it. Have you ever heard about this kind of tool?

If you do a memory dump of the NES once the BASIC programme is running, I think you could pretty much turn that into a ROM that anybody could run, which is one way to do this without all the hullabalou, but it wouldn't be as interesting as coding to disk directly.

-Xious

by on (#66708)
Look, all of these ideas suffer from a "bootstrapping" problem. You'd need to burn ROMs or do hacking to FDS disks to get this BASIC running on a disk, so if you have such technology, why not just program stuff and burn ROMs directly? Or even if Family BASIC can be put on an FDS disk (via hacking), then that means you're better off writing your own programs directly onto the disk rather than running it through BASIC.

Alternatively, since Family BASIC uses the tape data recorder, why not just distribute BASIC creations as sound files over the internet?

by on (#66713)
ccovell wrote:
Alternatively, since Family BASIC uses the tape data recorder, why not just distribute BASIC creations as sound files over the internet?

Because FLAC is big, and psychoacoustic codecs like Vorbis might fornicate up the phase information that all cassette interfaces used to store data. But then if we can emulate the saving code, we can generate a wave file with a tool on the user's side.

by on (#66722)
tepples wrote:
ccovell wrote:
Alternatively, since Family BASIC uses the tape data recorder, why not just distribute BASIC creations as sound files over the internet?

Because FLAC is big, and psychoacoustic codecs like Vorbis might fornicate up the phase information that all cassette interfaces used to store data.
Seriously? That's a damning problem? I didn't even mention your dread word MP3 but you get on everyone's case anyway. :?

A short audio clip in raw PCM format never overloaded anyone's bandwidth.

by on (#66727)
If FLAC is big, uncompressed PCM is even bigger. And some of us (e.g. VirtualNES developer Jamie Sanders) are still on dial-up because cable and DSL haven't reached Bufftuck Kansas even if 2 Mbps DSL has reached my sister in Bufftuck Indiana.

I'm not on anyone's case, just trying to find the most efficient way to distribute binaries. That's what the sentence after what you quoted was about: finding a way to distribute a smaller file that can be used to generate such a PCM file.

by on (#66730)
I still need to put this on the main page, but here it is:
Image

sepi made this, I haven't built one yet to try it out. It would be cool to be able to save tracks in Excitebike.

It couldn't be all that hard to "digitize" the sample, could it? I mean converting both ways between PCM and the original bits/bytes. There is already software to do it for other systems that used tape drives, so maybe that same software might already work.

by on (#66941)
So, the datacasette samples use the $4016 address line (R1 and W0)?

That's interesting... I would have thought that the audio line on the FC port would be used for part of it, but I haven't examined the signal paths on a FBKB yet. I guess that the KB converts that datacasette signals directly to $4016 reads and writes.

I was pondering this when making my pinout charts, as the FC doesn't have audio in available on the EXP port, so I suspected that it went over either $4016 or $4017, but I thought that the FC uses the analogue audio data directly over pin 2 (NES EXP pin 21).

If this is the case, I will have to add mini audio jack lines to the NESpander using this design as part of the final product., for those without the keyboard. Pretty easy to stick in the design somewhere...

-Xious

by on (#66943)
Quote:
Because FLAC is big, and psychoacoustic codecs like Vorbis might fornicate up the phase information that all cassette interfaces used to store data. But then if we can emulate the saving code, we can generate a wave file with a tool on the user's side.


If space is a real concern you could convert the PCM data into PWM, which should reduce its size given the special properties of the waveform. Or better yet, convert it into the corresponding binary file (i.e. the actual machine code, not an audio representation of it).
It should be possible to convert the data back into PCM if you need to put it on an actual cassette tape later. Tools like that have existed for C64 tape processing for a long time AFAIK.

But for those not living in rural Kansas plain WAV files put in a .7z will probably suffice. ;)

by on (#67427)
I hope this is relevant, I stumbled up this blog-post yesterday. Either way it's cool:
Using Python to Encode Cassette Recordings for my Superboard II

It has 2 more parts, and includes sample code. Maybe something similar could fill the niche here, following tepples' suggestion.