Jump to content

Chilly Willy

Members
  • Content Count

    842
  • Joined

  • Last visited

  • Days Won

    1

Everything posted by Chilly Willy

  1. You could make a SNES save state device, but it would need to be internal rather than a cart. I wonder if anyone has tried that...
  2. I think it's the same issue as the z80 state in the MegaED states - it's a separate bus that can't be monitored from the cart slot. MED's save states can't save the exact state of the z80, so he fakes it. It works on some games, and not on others. You would have a similar issue on the SNES with the sound at least, maybe some other stuff as well.
  3. My Amiga crashed about as often as Windows XP. Certainly more often than linux or Windows Vista/7/8. You just can't compare any old OS to brand new ones. Then again, try running a new OS in 256 KBytes of ram.
  4. The MegaEverDrive is the only flash cart with save states. Note that save STATES is not the same thing as save RAM. All flash carts have save ram. So games that save to save ram work on any flash cart. Save states is like emulators where you can save at any time in any game, not just ones that support save ram. The MED save state function doesn't work through the 32X, only on a bare Genesis. The MED also supports 8 and 10 MByte flat roms like that Mortal Kombat hack, but again without the 32X or the SCD attached. You simply can't do 8 or 10 MB roms with a SCD or 32X attached with any cart. I don't know what the deal is with save states and the 32X... might be kinda like playing SMS games through the 32X (certain lines not passed through). Which is the other thing flash carts can't do - play SMS games through a 32X without hacking the 32X.
  5. There were quite a few VGA game ports that allowed the Mac user to control how the 320x200 VGA screen was drawn on the Mac 640x480 display. For example, Dark Forces had options for scan-lines (skip every other line), doubled-lines (repeat every other line), a straight centered 320x200 display, or full 640x400/480 display (slowest).
  6. I know I can, I just don't want to open up my 65XE and hack it. The source I was quoting from has it wrong... I thought that looked a bit slow! Thanks for the correction.
  7. I didn't ask for anything new, I asked for a bug-fix on the assembler that just happened to be found in assembly turned out by the compiler. That same bug could have been found in hand-written assembly just as easy.
  8. The FCC at the time were the cautious ones. Atari had those "buckets" of aluminum because that's what you needed to be FCC certified at the time. The instant the FCC relaxed the rules, Atari used cheaper/lighter enclosures. I run my SD2SIO at 57.6. The next higher speed (115.2) doesn't work on my 65XE. Reading up on that, the serial on the Atari can be a little iffy on certain models at that rate because of clock delays. There are ways to fix it, but 57.6 is fine with me. It's three times faster than default, and the SD card means never worrying about interleave and the like.
  9. For many people, C is just easier than assembly language. While it's ultimately better to use pure assembly on the GPU or DSP, many folks could get by for many games with C. Having the C compiler for the GPU/DSP means people who would otherwise not use them because they aren't comfortable with assembly can actually use the GPU or DSP. It's like Raptor - rather than force people to write GPU/DSP assembly, Raptor allows folks to use the GPU and DSP for predefined actions. The C compiler would be like that, only more flexible but not as fast.
  10. Apple 2 Disk 2 = 1500 baud. CBM 1541 = 2400 baud. Atari 810 = 19200 baud. Do the math!
  11. I figured he was going to throw the Jaguar through the window and loot the place.
  12. How about an old gcc compiler error? This is a test file generated by the old AGPU GCC: http://pastebin.com/y8gqTLgW You get this from rmac: This test file gave an error at the same line in smac. The problem was that the compares were all using the wrong checking of the argument types. Not saying that's the problem here, but it would be the first thing I checked given what I found in smac. Changing the compares in smac to do the same check as done by the subtract operation fixed the issue.
  13. Can't be used by Windows, you mean. Linux has a method of sending data in a compatible manner to any type of parallel device, be it USB or anything else. Of course, you'd need to change lo_inp.c to use the that, but it's an easy fix. Just use the io functions from the parallel.c file from the ucon64 source. For example, this is how ucon64 handles inputting a byte: unsigned char inportb (unsigned short port) { #ifdef USE_PPDEV int ppreg = port - ucon64.parport; unsigned char byte; switch (ppreg) { case 0: // data if (parport_io_direction == FORWARD) // dir is forward? { parport_io_direction = REVERSE; // change it to reverse ioctl (parport_io_fd, PPDATADIR, &parport_io_direction); } ioctl (parport_io_fd, PPRDATA, &byte); break; case 1: // status ioctl (parport_io_fd, PPRSTATUS, &byte); break; case 2: // control ioctl (parport_io_fd, PPRCONTROL, &byte); break; case 3: // EPP/ECP address if (!(parport_io_mode & IEEE1284_ADDR)) // IEEE1284_DATA is 0! { parport_io_mode |= IEEE1284_ADDR; ioctl (parport_io_fd, PPSETMODE, &parport_io_mode); } read (parport_io_fd, &byte, 1); break; case 4: // EPP/ECP data if (parport_io_mode & IEEE1284_ADDR) { parport_io_mode &= ~IEEE1284_ADDR; // IEEE1284_DATA is 0 ioctl (parport_io_fd, PPSETMODE, &parport_io_mode); } read (parport_io_fd, &byte, 1); break; case 0x402: // ECP register printf ("WARNING: Ignored read from ECP register, returning 0\n"); byte = 0; break; default: fprintf (stderr, "ERROR: inportb() tried to read from an unsupported port (0x%x)\n", port); exit (1); } return byte; #elif defined __BEOS__ st_ioport_t temp; temp.port = port; ioctl (parport_io_fd, 'r', &temp, 0); return temp.data8; #elif defined AMIGA (void) port; // warning remover ULONG wait_mask; parport_io_req->io_Length = 1; parport_io_req->io_Command = CMD_READ; /* SendIO ((struct IORequest *) parport_io_req); wait_mask = SIGBREAKF_CTRL_C | SIGBREAKF_CTRL_F | 1L << parport->mp_SigBit; if (Wait (wait_mask) & (SIGBREAKF_CTRL_C | SIGBREAKF_CTRL_F)) AbortIO ((struct IORequest *) parport_io_req); WaitIO ((struct IORequest *) parport_io_req); */ /* The difference between using SendIO() and DoIO(), is that DoIO() handles messages etc. by itself but it will not return until the IO is done. Probably have to do more error handling here :-) Can one CTRL-C a DoIO() request? (Or for that matter a SendIO().) */ if (DoIO ((struct IORequest *) parport_io_req)) { fprintf (stderr, "ERROR: Could not communicate with parallel port (%s, %d)\n", ucon64.parport_dev, ucon64.parport); exit (1); } return (unsigned char) parport_io_req->io_Data; #elif defined _WIN32 || defined __CYGWIN__ return input_byte (port); #elif defined __i386__ || defined __x86_64__ return i386_input_byte (port); #elif defined HAVE_SYS_IO_H return inb (port); #endif }
  14. I'd guess the development rom init that occurs before it checks for the bypass button (B) is causing an issue with the cart's init of the system. Or maybe the way they start the cart on bypass skips part of some init the cart boot code runs, which leaves the console in a state it can't handle. Just some guesses...
  15. As the owner of 5 different 64K Ataris and nothing else, I approve of the memory usage of the current demo.
  16. You might try reposting the mock up again. With the release of Raptor and Raptor Basic, someone might just take a shot at it now.
  17. Yes, that cable should work with the adapter. If you get Protector:SE, you don't need to mod the Jaguar. All you need is the adapter and DB25 cable. That's the great thing about Protector:SE - no modding needed. The mod kit has you put a BJL rom into the Jaguar to load BJL software, but Protector:SE has that same code in the game cart. Just hold "4" as you turn on the Jag to do the 4-bit BJL load, hold "8" to do the 8-bit BJL load, or hold nothing to start Protector:SE.
  18. 1.7c. It's from Dec 2014. Vbcc doesn't have a backend for jrisc yet. You need separate compiles of vasm for different cpus. Yeah, I can see how that would put a damper on mixing 68000 and jrisc assembly in the same file.
  19. The code is pretty hairy (smac or rmac). Have you looked at vasm? I wonder how hard it would be to make the jagrisc target of vasm handle "standard" Jaguar directives and such.
  20. Okay, this is really weird. I checked that I'm using the latest rmac, and I am. Then I tried using it for tube_se... and now it works fine. Why wasn't it working earlier? It gave a list of errors a page long, so I switched back to smac. Now, not an error. My brain is melting. Does rmac support more than a.out format for the output object files?
  21. Cables may be hard to find, but the adapter is still available at places like this: http://morethangames.a8maestro.com/prodgame/adv-gj0002-3.htm Use one of them with a DB25 extension cable and Bob's your uncle! That what I did before I got the skunkboard. Of course, you also need something that supports BJL - I got Protector:SE just for that purpose. That way I had a decently fun game as well as the ability to load software across the BJL cable.
  22. I did. While smac (32-bit only) runs through the assembly for tube_se just fine, rmac kicks out tons of errors. You might grab the source and figure out what's causing them. As to 64-bit, smac is SOMEWHAT 64-bit clean, but has issues with the tokens (and maybe other stuff, but certainly with the tokens). Looking at rmac, it looks like you cleaned up the issues with the tokens. So I'm willing to admit I was wrong on that... I probably assumed that the errors rmac had with the tube_se assembly was a 64-bit issue like it was with smac.
  23. Spoke too soon about everything looking okay. If you look at the listing, you see 129 00000046 CC03 move PC,return 130 00000048 0C83 addqt #4,return 131 132 ;*********************************************************************** 133 ; main loop goes here 134 ; it is assumed that "return" points to "triloop" 135 ;*********************************************************************** 136 137 triloop: 138 0000004A xxxx addqt #(skipface-triloop),return 139 0000004C 9064 moveta return,altskip And in the .o file you find "CC 03 0C 83 90 64", so we're skipping this. And now that I think about it, the above is a quick add that needs a sub32 expr to calculate the offset for the add.
×
×
  • Create New...