Jump to content

JimDrew

Members
  • Content Count

    121
  • Joined

  • Last visited

Community Reputation

73 Excellent

About JimDrew

  • Rank
    Chopper Commander

Profile Information

  • Gender
    Male

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. Yeah, I guess comparing pins 34 and 36 would be a good thing. So, I looked at the early CPU board schematic. I see how the HALT works. This won't be a problem implementing. It's just a simple condition.
  2. Thanks for the info! I will check the schematics to see how the external halt logic works, that will tell me what I need to know. Is there any reason why R/W could not be on both pin 34 and 36 at the same time? Pins 35 and 36 are normally not connected internally with the 6502 - but I am wondering if some slick hardware engineer found that these pins make great "vias" and used them that way in some design. I would hate to have add another set of gates and control logic just to handle pins 34 and 36 individually, if I didn't need to.
  3. Well, you definitely got that right! I had no clue that the Atari had a custom 6502. I was thinking that since it ran at >1MHz that the 'C' version (6502C) was the 4MHz capable chip! So... some questions for you... It seems that the pinout for Sally is identical to a standard 6502 with the exception of pin 36 now being R/W. Is pin 34 also the exact same R/W signal? I don't see pin 34 connected in an Atari schematic I found. Pin 35 is the /halt line, and that is very easy to support. I can take the address and data bus offline at any time - I do that already for the /RST signal. Is there some type of correlation of when the bus should go Z-state after the /halt line goes low? Most everything depends on a cycle state, such as RDY. Is there any documentation at all about Sally? I am going to make a 65816 emulation in the 6502 pinout so you can just drop this in an have a 65816. The emulation will run a bit faster than the 6502 emulation because the microcontroller I am using is a 16 bit version, and I am having to strip and swap bytes because it is little endian and I have to get the low byte for flags and register results. I don't have to do that when the 65816 is in 16 bit mode.
  4. My 65xxT just might be ideal for the Atari machines. You can set speed to be normal during any hardware accesses (mapped to whatever I/O addresses are needed). Taking the CPU off the bus (Z-stated) when forced to via the RDY signal is already supported, so there should be no issues with anything that needs the bus for access video memory. Since I control PHI1 and PHI2, those can actually follow the normal PH0 relationship, but multiple instructions can be executed (in a single PHI0 cycle) from internal memory when they don't require any slow down. So, the 65xxT is actually a variable speed CPU.
  5. Was this directed at me? The 6502 only has RDY as a means to halt it. I will have to take a look at the Atari schematics to see how/why they are needing to take the 6502 off the bus. BTW, I can make the 65xxT support the 65816 instructions by just changing the firmware. This is something that I will be doing for David Murrary's project, now that it has gone to a 6502.
  6. It supports RDY, which I assume is your HALT line? If so, as long as you adhere to the 6502 timing requirements (pulling it low during PHI1) then it should have no problem. I actually control PHI1 and PHI2. I can change these asynchronously to the PHI0 to increase the speed of the 6502 without needing a faster external clock. That is one method of operation, which seems might work pretty well with the Atari if it has 15ns RAM (as stated above). Otherwise, with the 65xxT you set accelerated/non-accelerated regions that you want. This is to allow things like VIAs to operate at their normal clock speed. You can also move any ROM into the 65xxT's internal memory map so that it is always accelerated. There is 32K of cache memory and the zero page and stack can always be (or never be) cached. It's pretty fast, with the ability to execute up to 8 complex instructions within 1us. A single complex instruction normally requires 6+ cycles. Currently, the 65xxT supports the NMOS version and all of my testing so far has been done with the Commodore 1541 disk drive. So, all illegal opcodes are supported. I am currently working on obtaining information for the hundreds of various stand-up arcade machines because this can be used as a diagnostics tool to test RAM/ROM/Peripherals (who knew?). I plan to add support for the 65C02 as well as make different pinout versions for the 6510, 8502, and a couple of other 6502 variations. This same design will also be spun into a version for the Z80 and 6809E. The board uses a dual core 190MIPs microcontroller, with the code written in hand optimized assembly. I will say that I do have an Atari 400, 800, and 800XL here - but I have only looked at them enough to know where the 6502 is physically located to make sure that the 65xxT will fit. Other than that, I couldn't tell you how to boot a disk with an Atari system. I do have a couple of 1050 drives though should I get brave enough to try! My focus has not been on Atari systems, but I will doing some testing when I get some free time. I plan to release this at CRX 2019, to be used with Commodore 1541 disk drives, and VIC-20s... maybe more system (Apple II, Atari, etc.) by then? We shall see.
  7. Well, it's coming! I am negotiating with a couple of programmers right now to add the ability to mount a floppy disk through SuperCard Pro (USB interface) as a drive letter under Windows. It will first be MS-DOS format, but the filesystem handler will be modular so you will be able to choose the filesystem (or perhaps that can be automated based on the disk type) for Amiga, Atari ST, Atari 400/800, C64, etc.
  8. So, since I am not Windows device driver guy I have put up a project on Freelancer to find a Windows programmer that can create a Windows device driver/file handler where I can fill in the Windows code required for reading/writing sectors with the SuperCard Pro board. If I can find a person to do this we will be able to "mount" drive A: (or B:) on the Windows desktop and read/write floppy disks. I also want the filehandler portion of the code a separate module so it could be replaced (or added on to) to support Atari 400/800, C64, Atari ST, Amiga, etc. disks as a standard Windows drive letter.
  9. Sorry, but I just found this thread! No, I don't have any software (or firmware) where the SuperCard Pro can emulate a USB floppy drive. If someone knows how to write the Windows side filesystem handler, I would immediately add whatever support was necessary for sending sectors any whatever disk format was required. I just don't know driver level programming in Windows. You can use HxC Floppy Drive Emulator software to convert .scp image files to/from dozens of different disk formats commonly used with emulators. Several emulators also support either direct hardware access and/or .scp image file format.
  10. It works fine on the C128D, that's what I used for my original development. You need to change a jumper pad for the C128/D to work with BURST mode loading. This is due to the UP9600 baud hack support, which is not compatible with the C128/D. I made a jumper pad where you can disable the UP9600 support if you are using a C128/D. ANY USER port device, from EPROM programmers to audio capture devices does not work with the C64Reloaded Mk2 board without video interference. The WiModem is the same. For the Mk1 board you can remove the fake 8701 chip and replace it with a real 8701 chip and the video is now perfect - with any USER port device. There is a problem with the C64Reloaded Mk2 board (and Mk1 w/fake 8701) being too sensitive to the 5v rail due to the 8701 logic.
  11. Not hardly. The WiModem232 is my own hardware design and my own firmware, written from scratch. In order to make the communications truly asynchronous (so file transfers work perfectly) I also had to re-write part of the ESP8266 library. There are literally hundreds of hours into the WiModem/WiModem232 coding to make it 100% fully Hayes compliant. This is why people can (and do) use it for running a BBS. You might also want to note the timeline in history. The WiModem for the C64 came out years ago, long before other solutions started appearing. The WiModem and WiModem232 are commercial products with lifetime warranties.
  12. The WiModem232 responds to all Telnet commands with DON'T/WON'T. This seems to be enough to get telnet stuff running. With a WiFi modem you don't need a telnet connection, and frankly I am a little surprised that they are used at all because Telnet was used mainly for controlling remote dumb terminals (width, number of lines, speed, etc.) We don't use dumb terminals, we use terminal software which handles all of that. Telnet dramatically reduces the through-put and has difficulties with flow control as well. 99.999% of the time when you are "calling" a BBS nowdays, it is a direct TCP/IP connection - no telnet. There are literally hundreds of telnet commands that would have to be supported in order to be fully "telnet compliant". Since I didn't even know about telnet for 2 years after releasing the WiModem, I would say it's probably not worth the effort to try to support it for a handful of cases. I doubt there is enough code space left for full support as well.
  13. If you isolate pin 2 on the user port from the user port device, you can supply a separate 5v supply to device (along with ground of course) and that will resolve the issue. As long as the Mk2 is not supplying the +5v to the user port device then there are no video issues.
  14. Apparently using any user port device that requires power with the Mk2 cause the same display issue, not just the WiModem.
  15. That's a myth. There are no "pulses" sent by the WiModem. The problem is with the C64Reloaded's 8701 replacement circuitry. It is too sensitive to changes in the 5 volt rail. The exact same problem exists with the C64Reloaded Mk1 board *if* you use the fake 8701 board. If you use a real 8701 with the C64Reloaded Mk1 board there are no issues. Likewise, if you put the fake 8701 board into a C64 you will then have the issues. Also, if try to use several other user port devices, such as Jason Ranheim's EPROM programmer, the PP64 EPROM programmer, or the Covox Voicemaster with the fake 8701 board or the C64Reloaded Mk2 board, you will also have the exact same issue that is seen with a WiModem. So... let's recap: C64Reloaded Mk1 board with fake 8701 and WiModem, EPROM programmer, or digitizer = video artifacts C64Reloaded Mk 1 board with real 8701 and WiModem, EPROM programmer, or digitizer = perfect video C64Reloaded Mk2 board with WiModem, EPROM programmer, or digitizer = video artifacts C64 with fake 8701 and WiModem, EPROM programmer, or digitizer = video artifacts C64 with real 8701 and WiModem, EPROM programmer, or digitizer = perfect video
×
×
  • Create New...