PCEngineFans.com - The PC Engine and TurboGrafx-16 Community Forum
Tech and Homebrew => Turbo/PCE Game/Tool Development => Topic started by: syntacsugar on February 24, 2009, 01:39:04 PM
-
hey everybody,
just wondering if any of you can help me get started with trying to code things for the pcengine/turbografx. I have some programming experience and i'm always working on my programming skills, and i would like to make something for a console or any machine, since i love the pcengine i want to give it a try. so my questions are:
what tools are out there?
which should i use?
are there any tutorials or source code or smaller programs that i can look at to see how things work?
is there a special library to help with developement?
and is there a place to get a flash hucard?
also from what i've been able to gather you can code in asm or c++ which is best?
know of any resources/books to learn assembly?
i know it may be a ton of questions, but i have yet to find any place that could answer them. even getting back into programming like i have was a headache theres so many languages out there that its hard to know where to start or which to start with. i would appreciate it if anyone with any experience could point me in the right direction or share how they got started.
thanks
-
what tools are out there?
We usually write our own. I usually just write command line converter/utilities in C for PC - no GUI stuff. Nothing fancy. The assemblers and compilers also have some support for converting palettes, maps, tiles, and graphics for you. Though nothing fancy.
which should i use?
If you go the C route, then you have access of the internal function that can import MAPPY tilemaps. But the compiler generally generates slower code than even unoptimized assembly by hand.
are there any tutorials or source code or smaller programs that i can look at to see how things work?
I have a WIP tutorial - here (http://pcedev.blockos.org/viewtopic.php?f=5&t=27). Even if you choose not to code in assembly, the tutorial can help you understand the other hardware at a low level.
is there a special library to help with developement?
Both HuC C compiler and Magickit Assembler have a large library of useful functions. Though some of us are purists and and write out own libs for more speed and/or more functionality ;) It's not as difficult as it might sound.
and is there a place to get a flash hucard?
I highly recommend tototek over neoflash. The only down side to tototek cards is that they require a parallel port VS Neoflash USB connection. I never could get the tototek card to communicate with the parallel port on my laptop either. I didn't try to hard since it works with my PC.
You can also make your own if you have a general rom programmer. Hack up one of those 'barney' import converters and solder a DIP zif. Zif makes taking the DIP flash chip out for programming real nice :). Flash is easy to find (AM29F040B DIP version).
also from what i've been able to gather you can code in asm or c++ which is best?
Whatever suits your needs. HuC compiler is pretty decent IMO, but like all 65x based solutions speed comes from low level optimizations. HuC supports inline ASM functionality, but you have to be really careful not to step on the toes of the compiler's generated setup. Otimizations for speed on the PCE also come from having complete control of mapping in near/far data. You have much less control over this in HuC with inline ASM because of the compiler's setup/needs. If the PCE had a flat memory layout, then this wouldn't be an issue for the C plus inline ASM route.
A weird thing with HuC is that it only has support for 16bit variables. You can define "chars", but the compiler will treat the char as a 16bit var with the top half zero'd out. It also has some issues with treating some near data as far data, creating quite a bit of overhead in cycles. The compiler also has an its own stack system (not the real stack) for argument passing and it's really slow if you pass more than a single argument (single arguments are passed in two registers). So you'll have to use global variables for speed (write values to the global variables, then call the function), etc.
know of any resources/books to learn assembly?
There are a ton of 65x (6502) tutorials, docs, books, forums, etc on the net. The PC-Engine CPU is based on that 65x. It has additional instructions that Rockwell added when WDC licensed they 'C02 out in trade for fabrication (WDC weren't a large enough company to fabricate their own chips). Rockwell chips are usually referred to as 'CS02 or 'C02S. Anyway, you can learn on the original 6502 instruction set just fine, then take advantage of the newer instructions later. The original 6502 instruction set is very simple and easy to understand. It's an easy processor to learn on. Among the many sites, the 6502.org forum is pretty good for help in learning the 65x.
i know it may be a ton of questions, but i have yet to find any place that could answer them. even getting back into programming like i have was a headache theres so many languages out there that its hard to know where to start or which to start with. i would appreciate it if anyone with any experience could point me in the right direction or share how they got started.
thanks
My recommendation would be to go the ASM route. There's are a ton of retro platforms that used the 65x that are still very active (atari systems and computers, apple computers, C64/plus4/plus16, nes, lynx, etc) so the CPU is extremely popular. And there are people who still build small computer systems (SBC's) with the 65x, not to mention it's still widely sold for embedded systems. It's not a dead cpu ;) Even the 65816 (16bit version) is almost identical in code except the regs and arithmetic have been extended to 16bit. Almost exact same instructions. My point is, that you'll find plenty of support because of its wide use across platforms.
-
To learn/understand 6502, I say get the book Machine Language for the Commodore 64 and other Commodore Computers by Jim Butterfield.
Its not for the PC Engine, but it is still a good ML book...
here is a link to a buncha 6502/C= related books (pdf)
http://www.bombjack.org/commodore/books.htm
As for getting started you want to get a good text editor (Textpad, Notepad++!) and dive headfirst into some assembly. Itll save you headaches and such in the end. set up MagicKit and try out some source stuff and go to town.
also, a good paint program is pretty important. NeoPaint is my favorite. Grafx2 is also good, and obviously Photoshop.
good luck :)
-
thanks for the link..funny thing was i was looking at the atariarchive site and saw some assembler books but you can't dld them. i actually have a c64 time to dust it off and give it some use. i've started reading through one of them already, so i'm on my way . any place i can get some specs about the turbografx/pc engine . to learn more about the hardware?
-
if you go to here, the Magic Kit website:http://www.magicengine.com/mkit/
it has full docs on the hardware. Its all pretty quick reading and then you can just reference it when needed.
I wouldnt dust off your C64 and fire a real one up. All the hardware mishaps of it being so old will annoy and discourage you...
fire up Vice and do it there. It has a built in monitor and is alot easier than trying to set up a real C64 anymore. (There are also some cross assemblers and Cross-C stuff..)
-
wow thanks for that. lol i took my c64 out and everything even had to fiddle with the rf switches and everything. now i dont' have to fire it up then keep looking back at my monitor. and i really relieved that i can run vice on linux since thats what i'm using right now.but i've looked up vice and ive gone over to :
http://turbo.style64.org/tmp.php and got tasm. so i'm hitting the books, and od-ing on assembler thank god i dont' have to type it in !!!! is this a good choice of assembler to use?
-
tasm/tmp is THE only assembler you should use on a C64 lol.
but, why not just cut your teeth on 65SC02 for the PC engine?
You can use magic kit, the docs, and a book and get crackin and then compile/test on Magic Engine or Mednafen
-
i'm gonna take your advice on that, i've gotten tons of pdf's , got magickit, and some other cross assemblers, and i've been reading the book you suggested and looking at other asm tutorials.and i've just been write very small routines to see what they do..it's pretty interesting, i'd love to look at the source for some demo's. you know where i can find any? so far its been mostly c64 stuff i've come across, and the few i found linking of of the magickit site.
-
Several of my demos have ASM source code included: http://www.disgruntleddesigner.com/chrisc/creations.html
(They may not assemble perfectly with the latest versions of MagicKit, but they may prove instructive. :-"
-
(They may not assemble perfectly with the latest versions of MagicKit, but they may prove instructive. :-"
batcpy syntax changed, and the vsync stuff is different... :mrgreen:
so worse case scenario, you'll assemble a rastery one, it'll make you fix batcpy, then you will get it built and run it and realize all the raster swirling is not working.... its fixable once you know more of what you're doing.
but, other then that, they're informative. :-D
-
thanks...funny i think i may have come across that site before while trying to learn more about programming this machine.
-
So, who is the ASM programming guru I should contact? Or should I just post my questions here?
Thanks
Charlie
-
So, who is the ASM programming guru I should contact? Or should I just post my questions here?
Thanks
Charlie
post them here. they will probably get answered!
or pop into #utopiasoft on Efnet
-
Ok, so
In "huc.inc", there is this:
.zp
__sp
__stack .ds 2
__arg_idx .ds 1
__temp .ds 8
__ptr .ds 2
__fbank .ds 1
__fptr .ds 2
__expr .ds 2
There is no size for "__sp"; does this mean a default size value? What is it? Or does it mean something else?
Thanks
Charlie
-
shit theres an interesting question...
is it the stackpointer?
Hmm...
-
__sp is just a label.
Similar if I did this
array:
array_header: .ds 2
array_data: .ds 256
Even when using ram, a label is just a label. array points to the same location as array_header. A routine accessing __sp (which is an internal stack for arg passing, not the processor stack itself) might do something like; lda __sp+2 etc.
-
Ok,thanks, the lack of the colon confused me, as I thought labels always needed a colon.
So,
__sp
__stack .ds 2
is the same as
__sp:
__stack: .ds 2
Yes?
Thanks
Charlie
-
Ok,thanks, the lack of the colon confused me, as I thought labels always needed a colon.
So,
__sp
__stack .ds 2
is the same as
__sp:
__stack: .ds 2
Yes?
Thanks
Charlie
Correct. Though I always use ":" too (wow, that sounds soo dirty. (Wait! That wasn't a pun!. Ahhh man... #-o)). It's confusing sometimes without it and not as easy to spot (no laughing! .... dammit.).
-
OK, next question:
When I compile(?) the HelloWorld example with HUC, the resultant ".s" file has, as it's last couple of lines:
.bss
__arg:
(Minor question: Is "__arg" related to argc and/or argv?)
When I link(?) the HelloWorld example with PCEAS, the resultant ".lst" file has...gasp!..the same thing
(also at the end). And, slightly prior to the location of this label, is the directive ".bank CONSTANT_BANK"
Somewhat further back, there is another ".bss" section:
.bss
msflag: .ds 1
msvert: .ds 1
mshorz: .ds 1
And, slightly prior to the location of THESE labels, it the directive ".bank LIB1_BANK"
So, does this mean that, although both sets of labels are in ".bss" sections, they are not related to each other since they are in different banks?
--OR--
The ".bank" directive has no effect on the ".bss" directive, and all the ".bss" sections are sequential.
That is, in memory would they look like this:
.bss
msflag: .ds 1
msvert: .ds 1
mshorz: .ds 1
__arg:
Thus, "__arg", as a label, is in the memory location immediately/sequentially following "mshorz"?
Thanks,
Charlie
---------Modified/Edited----------
Sorry, Tom, I honestly do not get the pun! Should I translate ":" as "colon", therefore "I alway use colon too"?
-
Thus, "__arg", as a label, is in the memory location immediately/sequentially following "mshorz"?
Correct. BSS (and ZP) are only attached to bank $f8 (initial scratchpad ram of the PCE). BSS keeps its own counter and starts from $2200. Every time you declare a label and length, the counter is incremented. It doesn't matter where you use BSS or what bank. It makes code very portable and dynamic. Especially if you were going to write a lib for someone else to use, you don't have to include a separate variable list file. Take note though, the ORG directive does effect BSS.
If you were to do
.BSS
.org $2800
some_array: .ds 8
It does effect where it's placed in static mapped ram. It's not a good idea though to do that. The BSS counter will continue after $2800+8, so you'll potentially skip over allocatable ram/space. Or, if memory was already defined there, you'll get conflicting/overlapping addresses and the assembler (iirc) won't spit out any warning or errors. Using ORG before BSS has no effect on BSS defines.
Sorry, Tom, I honestly do not get the pun! Should I translate ":" as "colon", therefore "I alway use colon too"?
Yup.
-
Ok, thanks.
But both of my previous questions were actually to get some basic knowledge leading up to this:
If this is correct:
msflag: .ds 1
msvert: .ds 1
mshorz: .ds 1
__arg:
then I can think of it like this (example addresses)
$0000 msflag
$0001 msvert
$0002 mshorz
$0003 __arg
Yes?
So then how is code like this valid?:
sta __arg-(\1),Y
If the parameter is $01 and Y is $00,for example, I read this as "store the data in the A register into mshorz", which obviously is dangerous to the data in mshorz.
Am I mis-interpreting this code, or is it expected that there will never be a combination of parameter-and-Y values that cause this?
Charlie
-
Ok, thanks.
But both of my previous questions were actually to get some basic knowledge leading up to this:
If this is correct:
msflag: .ds 1
msvert: .ds 1
mshorz: .ds 1
__arg:
then I can think of it like this (example addresses)
$0000 msflag
$0001 msvert
$0002 mshorz
$0003 __arg
Yes?
Correct. (And just double verified by checking the sym file on a test file).
So then how is code like this valid?:
sta __arg-(\1),Y
If the parameter is $01 and Y is $00,for example, I read this as "store the data in the A register into mshorz", which obviously is dangerous to the data in mshorz.
Am I mis-interpreting this code, or is it expected that there will never be a combination of parameter-and-Y values that cause this?
Yes, it would store Acc into mshorz. Assuming you used that in a macro. Expanded it would be sta __arg-$01,y. But if you'd using Y index reg, why use a system like that?
-
It's in "huc_opt.inc", and it hurts!
But, I just wanted to make sure I had it right.
Ok, moving on....
This works:
========
.code
.bank START_BANK,"Base Library 1"
.org $E000
_reset:
sei ; interrupts off
cld ; clear the decimal flag
ldx #$FF ; initialize the stack pointer
txs
lda #$FF ; map the I/O bank in the first page
tam #0
lda #$F8 ; map RAM bank in the second page
tam #1
nop
nop
nop
bra *
==============
This doesn't work:
.code
.bank START_BANK,"Base Library 1"
.org $E000
_reset:
sei ; interrupts off
cld ; clear the decimal flag
ldx #$FF ; initialize the stack pointer
txs
lda #$FF ; map the I/O bank in the first page
tam #0
lda #$F8 ; map RAM bank in the second page
tam #1
jsr MySub
bra *
MySub:
nop
nop
rts
==================
Don't yet know enough to figure out why. Here's some hints:
1. Prior to this code is the typical "include" directive. The include file has the format:
(list of EQUates)
.zp
(list of ".ds")
.bss
.org $2680
(list of ".ds")
__arg: <==This should look familiar!!!
2. I am 99% sure the failure is at the "RTS" in the sub. My admittedly incomplete knowledge leads me to believe that the stack pointer is not being stored properly, and thus the Instruction Pointer doesn't return
back to the calling routine.
3. I note, with irony, that the include file does exactly what Tom said is dumb:
" .BSS
.org $2800
some_array: .ds 8"
Of course, I did not know until now that BSS starts at $2200.
So, could it be the ORG directive inside the BSS? How would that affect the stack operation? Or is it something else?
Thankls
Charlie
-
3. I note, with irony, that the include file does exactly what Tom said is dumb:
" .BSS
.org $2800
some_array: .ds 8"
Of course, I did not know until now that BSS starts at $2200.
So, could it be the ORG directive inside the BSS? How would that affect the stack operation? Or is it something else?
Ohh... That has to do with the CD system card. On the system card they reserve some ZP space and a chunk of ram from $2200-27ff(or maybe 26ff , don't remember offhand) for internal registers and stuff. HuC tends to mimic the system card even for hucard projects. The video interrupt system for hucards also mimics the system card one.
==============
This doesn't work:
.code
.bank START_BANK,"Base Library 1"
.org $E000
_reset:
sei ; interrupts off
cld ; clear the decimal flag
ldx #$FF ; initialize the stack pointer
txs
lda #$FF ; map the I/O bank in the first page
tam #0
lda #$F8 ; map RAM bank in the second page
tam #1
jsr MySub
bra *
MySub:
nop
nop
rts
==================
How do you know it doesn't work? You've stepped through it in the mednafen debugger? Assuming that's the very first thing from the reset vector, that *should* work fine. Stack is initialized, ram is mapped, interrupts are disabled, hardware bank mapped. Call mysub, return, then infinite jmp.
-
ok, given the "That has to do with the CD system card......." stuff, I can (or should) move the org to
$2000, or maybe even remove that directive totally and .BSS will default to it?
Don't know what a system card is/does.
"How do you know it doesn't work? You've stepped through it in the mednafen debugger?"
Used a hardware emulator/debugger, don't know what a mednafen is/does. The RESET vector definitely works. I have similar code snippets on both the TurboExpress and the TurboGrafx16, and both fail in the same way. It is also quite possible that I have mis-configured the emulator. I was just hoping that there would be some glaring error in the code relating to some specific TE/TG16 hardware setup that I was missing, like maybe another TAM configuration; that is the main reason this is such simple code, without multiple blocks/sections, etc. If you are reasonably confident this is good code, I'll go back and do a "redo from start" (Ha! remember that?).
Thanks for the help
Charlie
-
system card is for CD ROM system attachment....
and Mednafen is a command line emulator with a built in debugger. Check it out and be sure to check the debugger manual too so you are using it right :)
-
ok, given the "That has to do with the CD system card......." stuff, I can (or should) move the org to
$2000, or maybe even remove that directive totally and .BSS will default to it?
Well ORG $2200 - cause ZP is 2000-20ff and stack is 2100-21ff. But by default it starts off at $2200.
Don't know what a system card is/does.
Just a bunch of subroutines (bios) for CD games But it reserves/setups the main ram bank. Not really much of a problem because for CD games, it's all ram.
-
HA! I was going to ask this next:
"cause ZP is 2000-20ff and stack is 2100-21ff"
And I guess this ram is located inside the console, rather than on the HUC card. What I'm going to do next is to do an "STA" into ram, then attempt to read it back. This should tell me whether or not I can actually access the ram; if not, I certainly can't expect the JSR/RTS to work.
Thanks for your assist.
Charlie
-
First step success! I can now write-to/read-from RAM, and therefore JSR's work. Here's some pictures of my prelim HuCard simulator:
1.Full PCB
(http://i721.photobucket.com/albums/ww214/charliee1151/Picture18004.jpg)
2.Inserted in TE
(http://i721.photobucket.com/albums/ww214/charliee1151/Picture18003.jpg)
3. Close up
(http://i721.photobucket.com/albums/ww214/charliee1151/Picture17003.jpg)
My test proggie is simple, a lot of NOP's and one JSR. But at least I am talking to PROM-vs-RAM with proper address decoding. (The ribbon cable connects to the IDE/emulator)
Charlie
-
wait wait
youre making a board thingy that will let you send code from PC to huCard slot?
-
ahhhh....yes. Is there a problem with that? I'm sure it's not illegal or anything like that (is it?)
Also got some prelim bank encoding working, now need to see if I can combine the two; maybe put a Gosub in each of the banks; maybe put a series of Gosubs to all the other banks, in each bank.
Note that I've repeated: this is prelim!
Charlie
-
no theres no problem. I just want to have one :)
-
Well, it's a little early for that. Remember this thing is still prelim (hmm, I may have mentioned that once or twice); I still have a lot of software tests to run to be sure the hardware does what it should.
If you're looking for an IDE type environment, you'll need more that just this board. If you just want something-a-prom-can-plug-into, the board alone would be ok, but you still need someway to program the prom itself.
Either way, you need the appropriate progs to create/compile/assemble/link your source code.
Charlie
-
what programs are you using to test things?
-
I have two so far, both include different bank setups with single level gosubs and write/read of ram. I still need to test nested gosubs (say, 20 deep). Next step after that would probably be IO, or maybe video.
By the way, I'm sure you know that there are numerous HuCard "equivalents" already available out there; I found a bunch of them via Google.
Charlie
-
Status update, "Hello TE World!":
(http://i721.photobucket.com/albums/ww214/charliee1151/Picture19001.jpg)
(http://i721.photobucket.com/albums/ww214/charliee1151/Picture19002.jpg)
Charlie
-
sweetness.
You just using HuC/PCEAS and sending code over? or how is it all working.
I am intrigued :)
-
Happy to oblige.
What you don't see off-screen is a PromEmulator. That, of course, connects to the PC. So, I write my stuff in ASM, assemble it with PCEAS which of course creates a ".pce" file, download that file to the PromEmulator via the parallel port, then run it. (The download and run is of course controlled by the Windows app on the PC).
When it runs, it resets the TE (that's the blue wire - this way I don't have to keep turning the TE power on and off), then runs the my proggie.
Lot's of caveats here though. I said in a previous post I had tested "bank switching", but maybe not. I'm a bit confused with the terminology; it may be "page switching". Also, the proper term might actually be "jumping" instead of "switching". Basically, in my test proggies, I'm assigning?/defining?/congifuring? the standard 2k blocks?/sections?/pages?/banks? in the EProm to various sections-of-useable-memory (MMU?/TAM?) indexes in an attempt to prove I can jump around the EProm cleanly. One example:
Start at $E000 Logical, $0000 Physical
Jump to $C000 Logical, $2000 Physical
Jump to $A000 Logical, $4000 Physical
Jump to $8000 Logical, $6000 Physical
So, did I jump banks or pages? Or maybe blocks? And, I'm pretty sure I have NOT switched /bank/pages; correct?
So, I'm not yet sure that capability exists. Also, I'd like to test the use of more than just four of the 2k blocks/pages, but I have not looked into that yet. And, of course, I still need to test sound and joypad. But all that may have to wait until I am more confident in my software knowledge.
Just had a thought! The above IS what you were asking, right? Or did you want to know more about the PCB itself?
Charlie
-
the specifics for sending data over are what I am curious about. Because that would be a way nicer way to test games/code than on an emulator!
I am very awful at explaining things, so I don't want to confuse you with trying to explain the answer to your question. :) Its pretty bad usually when I go about explaining technical stuff.
I think if Tom or Ccovell post, they will answer in a way that makes sense....
-
Well, there are indications that the emulator I was using was not faithfully reproducing the functionality of the TE hardware, so I made the "mini-card". As I mentioned above, I cannot confirm to what degree it actually emulates a full blown HU card, and, at the time, that was not a concern of mine anyway.
As for the "sending data", the data goes to the PromEmulator, which is a commercial piece of hardware I purchased a while back for many hundreds of $$. (That's why my previous post mentioned finding a do-it-yourself unit on the 'net). That's what connects to the PC parallel port. The emulator is actually a pack of ram chips that are "programmed" with the code by virtue of simply storing the data into them, just like any ram. When you run the emulator, the RAM acts as a prom simply by disabling the write function and outputting their data (the program) on the data lines, based on the address the TE cpu sends, just like prom. Consider programming an Eprom chip and plugging it into the socket instead of the ribbon cable; same difference, but you get real-time debugging capability.
I suspect that, to emulate a full blown HU card, so as to run prom-dump games, I will need a lot more complex board. But, since that was not a requirement at the time, and given that I'm writing the stuff in ASM, and not using any of the HUC libraries, etc, I can write a LOT of code in 32K of prom...as soon as I get a better grasp of the required software manipulations of the hardware, specifically of that "bank switch" stuff.
After re-reading my previous post, I realize my question was not to clear anyway. I should probably wait until I know a bit more, so as to ask questions more clearly.
Charlie
-
The most important part of the layout is the connector represented by the "fingers" of track at the bottom of the board. You need to exactly match the size, spacing and position of the original HU card so your PCB will slide dead center into the TG. This problem is easily(?) resolved by track positions within 0.003 inches (that's 3 one-thousandths of an inch!).
Wow. I think I'd have to create the PCB etching mask at a much larger scale, then shrink it down to get that kind of tolerance.
A more significant problem is the realization that the PCB thickness is NOT the standard 0.032 inches or 0.064 inches, but is in fact 0.096 inches.
I don't think anyone here would have a problem with two boards glued together. Nice to know that I can run traces on both sides of the main board, and protect the bottom traces with unplated PCB.
You should get a 90+% board yield, just probably not on your first try.
Heck I'd be happy with 1 good board out of 6 on the first try. Later runs would need a better yield to make it
break even economically (can't afford too much scrap), that's why I asked.
...The first is that the TG is 5V on the HUcard ports, so generally you want to use 5V parts. The second is that there is a commercially available programmable card that uses 3.3V parts, but has the ability to work compatably with 5V stuff. However, those parts are very expensive.
That's what I was afraid of. Nobody could afford a HuCard style game if the basic board cost $50.00 to make.
But, I think I'll look into lot prices on 27256 eeproms. If they're not too much ( I remember buying them from Radio Shack at a buck or two each), maybe I'll see about actually doing this...
The particular board in that picture includes a RAM chip.....
That's what I thought, and all I can say is ..sweet... No more 8K limit for all the program variables. I could map the Ram into the upper pages, and use it as sound / graphics buffers.
Unpack the stuff for each level into the card RAM, and send it where it's needed.!
-
"I think I'd have to create the PCB etching mask at a much larger scale"
Not necessary. Today's PCB layout programs are good to 1/2 of one-thousandths of an inch.
"Nobody could afford a HuCard style game if the basic board cost $50.00 to make"
Depends upon the board house. Some will do prototype boards for ~$35; you get 2-5 boards. My prototypes were considerably more than $50 for 2 boards, but I paid for upgrades. (Notice that those upgrades did NOT include a silk screen!)
"No more 8K limit for all the program variables"
Well, ok. But remember that to get that block of ram, you give up a block of rom. And, you can't necessarily take a 1 MB prom, add some ram of 8KB bytes, and expect to have 1MB-8KB of usuable prom left over. Check your address decoding.
I'm interested in the hardware details of your intended card. Do you intend to program your eproms somehow, and then solder them onto the board? Otherwise you need a socket. Just remember that my product was for program development purposes, yours is apparently for resale, so our efforts are in parallel, but not duplicates.
Charlie
-
... yours is apparently for resale...
Not necessarily. It would depend on how well it worked out. But it's easier to justify if I approach it as a commercial product. And, if I make a good enough case for it, I might be able to talk someone I know into putting up $$ for the equipment (ie, etching kit, eprom programmer, etc). Otherwise, I might have to do most of it -completely- from scratch. (DIY eeprom programmers are all over the net)
My thoughts about this run sorta like this:
We Know it CAN be done. No One has shown a commercial product, though. We've seen carts for the various systems produced by homebrew devs, so, why not the pce?
Well, the first problem is cost; to even get it off the ground, you need an eprom programmer, some way to create the pcbs, and the parts. It might be neat to do for fun or research, but if its going to be 'commercial' it would have to be done at a very low cost.
Low cost doesn't necessarily mean cheapest possible, but it does mean I have to minimize cost. That implies that getting someone to produce one-off proto boards is out - even assuming really good pricing, based on your figures, it's still about $5 a board. And after our experiences with getting CDs replicated, we're pretty leery about using outside people for production. That's why I was asking about etching the boards myself.
As for the boards themselves, I figure we would need a couple of dev boards, using UV Eproms; Say 5 for
easing the calculations. A 256Kbit EEPROM like that runs around $5.00. But, once the code is working and tested, we can switch over to OTP EEproms, and cut that cost down to about $3.00 each.
And yes, sockets are a necessity! (I've blown too many chips by overheating them, in a hurry to get the circuit built. Sockets help prevent such disasters ) So are pin-compatible parts.
I didn't see much else on the board you built; If we figure $10.00 for complete parts to do it all (per board, and yes that's probably overpriced), and another $5.00 for the pcbs (again, probably overpriced) we're looking
at $15.00 per board.
Well, you get the idea, I hope. It cost about $600.00 to get insanity pressed; I figure I could do this, even buying a 'cheap' eeprom burner for that amount. So, assuming we make 20 cards, they would have to sell for
$30.00 each, which I don't really think is overpriced, to cover our investment. (And probably make a profit at that). So it's definitely economically doable. I just have to convince a couple of people to come up with the money :-)
As for the hardware side of it, I can see why you chose the eeproms you did. Almost all of the signals are straight runs directly to the chips, especially if you reverse the traces ala the JP pce. I -think- If I go with
a double-sided board, I can reverse the data lines 'underneath', and make a dual us/jp board. And, if I split the address space in half (we are using less than 1/2 of the available), I can add an inverter on A20 to select the
chips: upper half would be RAM, lower would be ROM. Not an ideal solution (and probably not for the first cards), and something to think about for later, but definitely doable.
My plans would be to take the cycle demo Aetherbyte has, burn it on a UV-EPROM (In case it doesn't work), and use the dev boards to make sure the game works, in both US and JP pces. Once we know that that works, and have some experience doing it, we could then start working on a Hucard game, much the same way we are doing with the retro pack. Something simple, but fun.
And then, of course, offer it for sale here, to the people who love the pce. I get the knowledge gained, they get a 'real' HuCard game, and, of course, Arkhan gets bragging rights :-)
edit: I was looking at the chips and their pricing. I assume 70ns would be fast enough (they're not that much more expensive than the 100ns ones). Think those would be okay for High Speed mode? I seem to remember running 150ns Ram in a 4MHz a long time ago, but want to double check.
-
OK, OK, OK, OK, and etc...
The clock speed in the TG is less than 8MHz. (I assume you can do the math).
Charlie
-
. It cost about $600.00 to get insanity pressed; I figure I could do this, even buying a 'cheap' eeprom burner for that amount. So, assuming we make 20 cards, they would have to sell for
$30.00 each, which I don't really think is overpriced, to cover our investment. (And probably make a profit at that). So it's definitely economically doable. I just have to convince a couple of people to come up with the money :-)
All in all it was about 1000$ to get it pressed, + all the legal fees!
I get the knowledge gained, they get a 'real' HuCard game, and, of course, Arkhan gets bragging rights :-)
we'd all get bragging rights.
-
Sorry, Charlie. Sometimes I do tend to ramble on.
So, arkhan. Think we can scrape together abut $600 to do a run of the light cycle game ? After checking the eproms out, the board would be pretty simple to do. We'd need about $100 for an etching kit (unless you wanna go the extra $$ and get them made to order), and another $100-150 for a decent eeprom burner.
Figure another $200 for parts, which mouser / digitek / jameco have in stock and we could probably have it ready for xmas. What do you think?
I'm pretty seriously thinking of doing it anyway, for s-n-g. Fuzzy would probably loan me the $$ / help me find the stuff on-line, so I may go ahead and do a very small run to see if it would work. Looks like I found my winter project :-)
-
Sounds good to me but I think wasting the effort on a dopey light cycle game isn't worth it. Maybe if I spiff up the visuals or some musics added.
-
I think I'm actually gonna try this. A 6x6 board should make 4 blanks, and it's < $10. I can go single-sided (Yeah, I already did the layout) for the test boards. Another $20 will get parts for all 4 boards, so all I need now is an eeprom programmer :-)
And the light-cycle game is just for testing - it's small, already written, and should work from eeprom. IF we decide to do it on a larger scale (ie, more than 4 boards), We'd need to go with double-sided pro made boards (there's 50+ through holes for the us/jap version!) . At that point, yeah, we'd have to write a game for it to make it worth while.
-
Update:
After playing with the pcb software and getting the circuit straightened out, I started working on home-brew etching of the board. Using the laser-toner method, and trying lots of different papers, I finally hit on something that gave (what I think are) decent results. Muriatic acid is now a 'hazardous material', so I went with a slightly slower route. The board etched, but it's not exactly usable - I may be asking too much from this method, since i have .010 inch traces, and almost all of them broke at one point or another. Interestingly, the board edge fingers look good.
I'm gonna give it another couple of tries; this really was my first (ever) attempt at doing something like this. But It looks like Charlie's right - if we wanna do this in quantity, we're gonna have to go to a board shop....
Anyone interested ? (Mooz- here's you chance for that proto-board....)
-
so thats why we havent heard from you in like a week