Jump to content

Bruce Tomlin

  • Content Count

  • Joined

  • Last visited

Community Reputation

74 Excellent

About Bruce Tomlin

  • Rank
    River Patroller

Contact / Social Media

Profile Information

  • Custom Status
    CD C9 01
  • Gender
  • Location
    San Antonio, TX
  1. The 7800's "laserdisc" port was literally nothing more than a fancy A/V port that also had the ability to replace the main Maria 14.3MHz clock crystal with an external input. From the looks of the schematic, all the genlock magic was probably going to be in the disc player add-on, which would connect to your TV instead of the 7800's RF modulator.
  2. A couple of weeks ago was the Classic Game Fest in Austin. There was one corner block that had a bunch of assorted homebrewers, particularly Atari 800 and Sega Genesis. Then I realized I had my laptop and tried to see if I could get my old stuff running, as I knew my make files were smart enough to start an emulator. The first thing that surprised me was getting a bunch of signed vs unsigned char warnings. It seems I had a newer gcc installed than when I had worked on that old code. After quickly changing them to plain (aka signed) char, my RPG demo wouldn't display the map tiles. I had a long time ago had troubles getting GCC to work with C++, in that the initialization code for C++ was emitting 68020 BSR.L instructions, which don't work on a plain 68000. I could never figure out where they came from. I had a script which built GCC 4.2.4 from scratch, and I thought it was something wrong with the way it built. I remembered that at one point I simply didn't put in the C++ initialization, and copied the m68000 libraries wholesale into some other target variants. I quickly wrote up a simple test of C++, and the initialization code worked. Hey, I like this newer compiler. But it got me started playing around with the stuff again. I looked at my "SDK" libraries, tidied them up, used a few GNU assembler macros to clean up cartridge header stuff, and other tweaks. I decided that I should use this "mystery" compiler, and make basic C++ support work in my SDK. Then I was shocked to see how large my binaries were, so I created a lite printf. I saved about 30k over the "default" printf, easily more than half the size of the binary. I looked at my font loader, which was a big array of 0x11FFFF11 stuff, and used some macro tricks I had come up with since then to make "__XXXX__" macros where I could visibly see the graphics in source code. And then I cut out the blank 00-1F characters to save even more bytes in the simple demo I was working with. Then I started trying to figure out where the hell that mystery compiler came from. I thought maybe it was a pre-built that I had downloaded from somewhere, but there was no evidence of it being from brew or macports, and nobody else was using 4.2.4. (The pre-builts that I had downloaded were for ARM.) Then I looked at the file dates, and found it was almost the same as the last change to my GCC build script, back in April 2016. That was apparently my previous attempt to play with Genesis code, but I had wanted to get C++ working first. This was actually the one where I had copied the libraries in an attempt to get C++ initialization to work properly. Then, not being able to get it working like I wanted, I gave up. My scripts used 4.2.4 because that was the highest version I could compile with my installed C compiler without having to install some other crap. So two days ago I started working on the build script on another computer (so I wouldn't mess up what I already had working) and tinkered around with it. Eventually I found what generated BSR.Ls that caused my original problems, in crtstuff.c, and was able to confirm which GCC library targets had them. Then I realized my original problem was that I didn't understand some things about how GCC multi-target libraries worked. In particular, I was using "-m68000 -msoft-float" in my make files. The problem was that soft-float is only for 68020 and later. GCC already knew the 68000 had no floating point hardware, and would have compiled soft-float anyhow. Using "-msoft-float" (in either order) actually overrode the -m68000, selecting a library compiled for 68020, which used BSR.L instead of JSR. Note that the only thing that BSR.L would get me, aside from not working on a regular 68000, was position-independent code, which isn't very important when you're compiling to ROM. I also realized that the "default" target if you selected no CPU type was probably m68020. And then I realized that all this was merely the canary in the coal mine in that all the newlib libraries were compiled that way too, so LBSR would have been a problem later, but harder to notice than a problem with startup. tl;dr: my problem was that using "-msoft-float" caused it to select 68020+ libraries. And my old code was older than I thought, dating back to 2009 and 2010, before I got my big job in late 2010. I guess I had never tried them with the newer compiler in 2016, or I would have seen the signed char warnings back then. I was too busy trying to get support code working. Also, my current code formatting preferences must have started in 2010, so I've got to reformat that old stuff too. So yesterday I started pushing my new library/SDK code to be my new default. I got Tubes to work, after finding a minor bug in my printf, but the RPG still won't show map tiles. And if I want to use a bit of C++ (I use C++ in embedded projects as "C with classes" aka "structs with functions"), now I can. I still need to clean up a lot more stuff, but I'll save that for when I actually have time to work on this in a couple of months. And that code savings with a lite printf? I looked at the old .bin files and that ~30K bloat was in the old stuff from 2009. Yeah, I really don't think I need printf to support floating point.
  3. FYI this never happened. There was rain the morning of the reschedule date, and apparently having rain forecast at all for that day caused them to cancel it again, with no re-schedule.
  4. This has been postponed due to rain (and holy crap is it raining), it will apparently now be shown on Wednesday May 8.
  5. http://events.mysanantonio.com/event/outdoor-film-series-cloak-dagger-vch7hnoie7 May 3, 2019, 7:00 pm - 10:00 pm at Mission Marquee Plaza, 3100 Roosevelt Ave, San Antonio, TX 78214, USA Price: Free www.missionmarquee.com Phone: 2102073905 The City of San Antonio World Heritage Office will host the annual Outdoor Movie Series at Mission Marquee Plaza! Join us for our FREE family friendly event including; entertainment, food trucks, and a showing of the featured film Cloak & Dagger (PG) on the original jumbo screen. Visitors are encouraged to bring lawn chairs, blankets and snacks to enjoy during the movie. Our grounds are pet friendly and on-site parking is available. The venue opens at 7 p.m. Movie begins 15 min after sunset!
  6. TEMPAD would still be in ROM. You need to put it in your RAM variables section. I'm not sure what assembler you are using, but the standard opcode is DS (define space), which means set the label to the current address, then add that many bytes to the current address. No data is left behind, which you want because this is for RAM, not ROM. So you would have a section for your RAM data something like ORG 7000H VAR1 DS 1 ; 1 byte VAR2 DS 2 ; 2 bytes TEMPAD DS 8 ; 8 bytes at this point the current address would be 700B. If you tried to make a binary from just these four lines, it would be empty. Later you would have an ORG 8000H and the start of your code.
  7. Yesterday I found a Dell 2407-WFPb monitor... 1200x1920 (16:10 hell yeah!) with composite/s-video/component/VGA/DVI inputs, and an Atari Flashback 5 in its original box, which I'm about to open up to see what it's made of and what can be done to it. Also, a 10th Anniversary edition of Myst... from 15 years ago.
  8. Crazy idea: SIO to VGA pinout adapter dongle, bonus points if rebuilt into the shell of a recycled SIO cable end. Maybe a shell could be 3D printed. Then you can just get a fresh M-M cable if the old one dies.
  9. Check this out... https://web.archive.org/web/sitemap/http://drushel.cwru.edu/ There's a lot of stuff in there, it might be possible to reconstruct the whole web site.
  10. https://web.archive.org/web/20120907142322/http://drushel.cwru.edu/6801/6801_src.zip When in doubt, always check archive.org first. I'm just surprised that it archived a zip file. So is there source code for other devices, like maybe a floppy drive? 6801_src.zip
  11. I just found an ASUS Z170 Deluxe socket 1151/DDR4 motherboard in the bins at a Goodwill. I was a bit confused that the actual motherboard was in the box, and not a previous board from an upgrade. So I get home, freak out at the prices that thing lists for new (I don't know if it's because it's awesome or because it's a couple of generations back), then realize that the socket has quite a few bent pins. In other words, some caveman was trying to build his own PC and screwed up. I'm going to try to see if I can find a good magnifier light and un-bend the pins, then find a cheap 6th-gen Celeron or something to make sure that it works. Of course any given pin could be something like a PCI lane for an expansion card, so there could always be lurking problems. But since I basically got it for 2 bucks, I'm not complaining. In the meantime I've snapped the socket protector back on.
  12. I saw this thread because it was bumped. I also have a Channel F box in the same situation, so clearly it's a "normal" way to find the box. I think i was even worse to begin with since some cartridges were in it, but those got moved into an 8-track storage bucket. Or maybe the cartridges were in the box to the other version of the console.
  13. They were a particular dark beige color with a matte finish. They were also crimped with the pinout flipped opposite from typical phone cables, you don't want to get that wrong, it could potentially damage the keyboard. They were also 4 wires. I can't tell much from that picture but it's definitely not a Mac keyboard cable. I can't tell whether it's 4 or 6 wires, but if it's coiled and 6 wires, at least you know it's not just a plain old phone handset cable.
  14. The biggest restriction would be the 256K window. The code relocation would be a lot of work, but far from impossible. It's been so long since I've looked at that stuff, but I think SMS mode does two things, it makes the cartridge slot work differently, and there is a different memory map from the Z80 slave mode for I/O. The games would have to be patched, but the big thing is that you aren't going to run any bank-switched games. I think it's possible for 32K or smaller games. One thing I've always wanted to do is port some Colecovision games to run on Genesis. The biggest problem is that the Genesis VDP doesn't support TMS9918 mode (one of the SMS card games won't work on the PBC because of this). It would also have a significantly different memory map and different VDP interrupts, so it would be at least as hard as porting a SG-1000 game to Coleco. And then there are the keypads that some games would need. I don't know if the Genesis can use a Coleco controller properly. If I did it, I'd probably try a cross-assembly port to 68000, sort of like how the 8086 could run 8085 code.
  15. Last weekend I found a Wii in the bins at a Goodwill salvage place in Austin, along with power brick, AV cable, light bar, stupid stand (as if I didn't already have plenty of all those), and a Wiimote without a battery cover. It was just missing the flap over the Gamecube ports. Later I noticed a 4GB SD card in it. Not bad for $1.59 (?) a pound. When I turned it on, it had a Mario Kart disc stuck in it. I remembered I had a box to Mario Kart and, meh, it already had a disc too, so now the box has two discs. After much messing around with tri-wing bits, I was able to open it and get it to eject the disc. After that it seemed to work just fine. The only thing that didn't work? That stupid Wiimote wouldn't sync. Fortunately I had a couple of extra nearby to confirm that it really was just that one control. If it'd had a battery cover, at least that could have gone to another one that needed a cover! I guess I can try it again with the pile of controllers I've been accumulating. If I really can't get it to work, I guess I can take it apart and use the plug for hooking up a Wiichuk or other thingy to I2C for a microcontroller project.
  • Create New...