But theres still the problem of sticking the cables back together after you have chopped the middle out of the plug (and its casing).
RunnerPack mentioned a while ago that he managed to chop an old 5.25″ FDD plug to fit the link port, and I was thinking that since they hae similar spacings you could also try an old ISA connector or even some IDC plugs chopped correctly to fit the port.
Another thing: a few weeks ago on both 64DD and PVB forums the ‘new post’ icon on threads started continuously showing all the threads/forums as unread, even those that are read/old.
A few site suggestions: (Apply to both PVB and 64DD.net)
* How about adding a preview button and/or smilies to the quick reply box? I always use that to make sure I didn’t screw stuff up. 😉
* When you log in, how about having it redirect to the forum instead of the main page, as this is what people log in for anyway.
I would suggest borrowing a few books from your local library and starting there. There are a lot of free C++ compilers out there if thats where you want to start, but it may be better tp start with (Visual) BASIC and learn the basic principles of programming with that before you do more advanced stuff.
Also, video game programming is generally different to application programming. Instead of the standard input/output commands you would normally use instead you’re continuously accessing memory locations for things such as video and controller input.
Don’t know of any good online resources. I started on QBASIC way back in the DOS/Win3.1 days, and over time progressed to Visual BASIC, and more recently learned Java/C++ over the past few years.
The fact that I had learned programming in general made it easier when the time came to learn the syntax of C++.
Firstly, as I don’t have a programmer a link port version would be nice, but as I don’t have a link cable, and will probably buy a Willem for ROM/PIC/AVR work, I’m not sure.
I’d love a programming competition, unfortunately none of us have the spare time to do so. I’ll be starting my programming diploma in a few weeks, so I’ll have even less time than I do now. 🙁
I thought we had information on how to do sound, its just that noone has carts to test it out. IIRC the first 4 channels are easy enough, its just the sweep/modulation and noise channels we haven’t fully figured out.
…Its a shame the VB doesn’t have sound interrupts. It would have made feeding the next note(s) in a music track a lot easier.
I know there’d be a lot of tracks, but I was planning on making a cart that takes up the entire area inside the cart, not just the size of the curent VB PCBs.
Hope that would leave enough space for routing.
This is the the EEPROM I was thinking of using. The 28C64 claims it can be read and written to like SRAM, but as it is EEPROM no need for a backup battery.
And as for the /ES problem, couldn’t you tie both /WE and /CE to it? And when you say /OE is disabled do you mean its high or low, because IIRC writing needs it high/disabled. You could also use CS2 because IIRC CS2 is only high when SRAM is accessed.
lol, your loader sounds exactly like mine, even my original ‘squeeze it into empty interrupt space’ idea. 😛
Only thing different is stopping COMCNT to signify end of transmission. That would allow some code to be dropped from the loader (albeit a few instructions), but would introduce a COMCNT poll upon each byte received.
As for the free space idea, I guess the program responsible for flashing the ROM would need to search through each interrupt and figure out which aren’t used. If all are used, hope that nothing else is using the area between the ROM header and interrupts.
…And on the 5 1/4″ FDD connector idea, any idea what its called? I’ve tried Googling for it, but all I’ve found out is the 3 1/2″ connector is an IDC-34 pin.
I have a ton of old FDD cables at home, but I’d still love to be able to find one I can cut down and solder on to a PCB, which if done right could house the USB microcontroller(s) and a USB socket for a PC cable to plug into. Unfortunately the cables aren’t PCB mounted. so even if I did use them I’d still have the FDD cable running to a board, instead of it fitting neatly underneath the VB/linkport.
…And as for the code, you never know – there may even be enough room to allow for a micro controller->VB->PC relay code allowing the VB controller to be used as a USB gamepad. 😉
Any ideas on just how we can make a cheap link port connector? I know about the SNES/N64/GC AV cable hack, but thats just too much mess & trouble for what its worth. I tink I remember RunnerPack saying something about a 5.25″ floppy connector, but I’ll have to confirm that. That, and those things are hard to come by nowadays.
And about a bootloader, any ideas of your own? I quickly dropped the idea of an internal bootrom on the cart as it would take up space, but that only leaves injecting the loader into each ROM as its copied.
If you’ve actually got some of this past the design phase I’d love to help.
As I said before I was originally thinking of using the CS and Exp(ansion) select lines in order to activate the flash /WE line. Problem is its been so long since I looked at this I’ve long forgotten what line activates when.
Last I remember I (think I) figured out one of the lines would need to be inversed for everything (ROM, SRAM/EEPROM and /WE) to operate happily, but as its just been too long, don’t take my word on that.
I just reread the 29F040 flash spec sheet recently and the whole rewrite sequence. It says it needs 6 codes to complete a sector/whole erase, and 4 to program a byte. Any idea if you can erase byte by byte?
Also, any idea if the erase/program sequence only needs /WE active during each command (with breaks in between)? The reason is that if you were to tie /WE to EXP it would go low (or high or whatever) after each byte is sent.
I’d be happy to write something to test erasing/programming. It’s been ages since I’ve done anything VB, and I have a few weeks of holidays coming up.
About the bootloader, In order to keep it as small as possible I was thinking of doing the following:
* absolute minimal code necessary to activate VB
* check to see if COMCNT line is high (this would be pulled high by programmer)
* if line low, continue to ROM boot address (actual address would be moved somewhere else in ROM to accommodate bootrom address)
* if high, set xfer clock to external, prepare for link communication (can’t remember exact method atm)
* set addr pointer to 0 (or somewhere)
* continuously poll (can’t remember addr name – bit that tells you transfer complete). If (xfer contents register) is not zero, copy contents of register to pointer, inc pointer by 1. If it is zero, reset pointer to initial location and execute RAM code.
In order to reduce code, an acknowledgement is not included, but may be needed
This code would allow you you posibly load a secondary loader into RAM, which would then do more in-depth communication and checking.
My hope is to keep it as small as possible in order to reduce the risk of running out of free ROM space. I was thinking of possibly using that null area within the header to store the original ROM boot location, in order to identify if the ROM has in fact been changed (AFAIK all ROMs+tools have that area as null).
…Thats all I can think of atm. I’ll try and look for my old notes on the select/enable lines.
For the easiest method of EEPROM programming I would suggest actually buying a chip programmer such as those available from Willem. Making a programmer from scratch would probably be a bit too hard.
This reply was modified 17 years, 11 months ago by lameboyadvance.
As for my in-console idea, I figured out you can actually upload code to RAM and execute it from there. I also decided that I could tie the flash /WE (write) pin to the (unused) pin used by the VB for expansion (for stuff such as DSP, which never happened). This would mean when you access EXP area it would in fact be using ROM area but with the WE pin active. One potential problem with that may be the code needed by the flash chip to erase and write might need the WE pin active for the entire duration of the special code sent to it (for the write to work), whereas this would in fact drop the pin back to low after each byte of the code is sent. As I don’t have a flashcart obviously I never got to test this fact.
I also decided on a barebones bootloader code that would be injected into each ROM upon write, which would do a minimalistic check of the link port to see if it was active, then begin transfer of the boot/flash ROM code over link port to RAM where it would be executed. This would mean only the most basic of code would need to be injected into the ROM, reducing the risk of lack of spare ROM space.
As for my LPT-based programmer idea, it would be reasonably easy as it could use a counter IC to increment the address lines of the cart, and control the cart WE/CE/OE/data pins and addr clock increment/reset pins via LPT. As it is already 5V there wouldn’t be any need for voltage conversion. One possible problem is that LPT data lines are 8 bits wide, and the VB is 16 wide, which would mean some way of buffering the 2 lots of 8.
…And of course the whole programmer cart socket again. Only source for those things seems to be a (hopefully) dead VB.
I may be interested in that idea. I have a few weeks holidays coming up soon, but I doubt I’ll use it on this. If anything I’m more likely to get stuck in and hopefully get my site back up.
The chips I use are AMD (AM) 29F040 PLCC-32. You may want to find a spec sheet on it for pinouts. PLCC seem to be the smallest 512K 5V flashchips that are still a solderable size. Most chips >512K are something rediculously tiny like TSOP and such. They measure about 21x25mm.
I doubt you have one, but you have a VB screwdriver/tool (either ‘official’ or a screwdriver or biro hack), you can open a VB cart and take a look at the PCB in there. Carts like Mario’s Tennis (non-SRAM) are actually tiny compared to the potential size in there. This would allow more than 2xPLCC chips, but the probelm is working the PCB track into that size, not to mention any additional flash/SRAM chips.
Another problem with a non-inconsole method is finding a cart socket to plug the flashcart into in order to flash it. This is another reason I want to make an inconsole model.
Finally, Lupin over at http://pokeme.shizzle.it/ has made a USB-capable Pokemon Mini programmer using USB consisting of an Atmel AVR (microcontroller). I’ve been in contact with him for ages, but haven’t gootten any real details from him about his software for it.
