This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.
Messages - RCtech
Pages: [1] 2 3 ... 5 Next
1
« on: June 03, 2013, 06:32 AM »
Printer cables with 25pol SubD to Centronics 36pol have a full layout. Serial cables for 25 pins often have not all lines connected, because only 3 lines are needed for RS-232. They're in the reduced 9pin-serial port. But these switches normally have all pins used.
2
« on: June 03, 2013, 02:11 AM »
You can try these 25pin SUB-D switching boxes used for parallel ports. You could connect four computers to one keyboard then. But I'm not sure if it's safe to switch while they computers are turned on. A safe way could be to use optocouplers on all lines. I think one or two lines of the C128's keyboard cable are unnused, they could be used for providing 5V in the keyboard.
Maybe somebody could build a parallel-to-serial converter sometimes, that the parallel connectors of the C128's keyboard will be converted to a serial cable using a clock and data signal. This would allow much thinner cables.
3
« on: June 01, 2013, 06:27 AM »
I had a keyboard which used electrically conductive rubber caps at the bottom which weren't working anymore, so I glued simple household aluminum foil over it. This worked perfectly.
4
« on: May 30, 2013, 05:08 AM »
Do you want to use this in direct mode or in a program? I would never use JiffyDOS commands in a BASIC program, always the official OPEN/PRINT#/INPUT#/CLOSE commands of Basic V2. I'm only using BASIC V2 commands, so I could made some programs which were able to work optimized on a real C64, in C64 mode of a C128 and in the native C128 mode. Even 40 and 80 column mode was detected and the output fixed.
By the way: If disk access in a program should be used, it's best to use the zeropage address 186 for the actual device number and 185 for the actual secondary address.
5
« on: May 30, 2013, 12:31 AM »
You also can get a input routine by opening a file to the keyboard, here's the BASIC code:
10 OPEN1,0,0:INPUT#1,A$:CLOSE1
It also doesn't print an ? and also needs no BANK command.
6
« on: May 29, 2013, 11:54 PM »
What device are we talking about? A CMD HD or FD? The default partition, so which is the one which is active at power-on or after a reset is set with the HD or FD Tools. Remember that the data are saved on the media, so if you are using a removable drive on a CMD HD (like I'm using magneto-optical drives), every media can have a seperate default partition AND device number! So one media could appear as 8 and one as 13 without modifying the CMD HD's settings. The FD has always a fixed serial number.
By the way, the first user-partition of a CMD device is 1, 0 is the System partition (type SYS in partition list).
7
« on: May 09, 2013, 05:09 PM »
Well, one way would be to copy a file from a real computer to a 1581 disk and create a .d81 image using 1581copy. Of course, this requires a PC with real floppy drive. That's maybe not actual at this case, but maybe something for the future.
8
« on: May 05, 2013, 12:08 AM »
The beginning should be a combined RAM/ROM/I-O board for the U36 socket. So it will be possible to add and control new hardware on the C128.
9
« on: May 04, 2013, 09:46 AM »
Hehe, I already thought if it's possible to display two INUFLI (Interlaced-NUFLI)-Images on an C128's VIC-IIe in interlace mode, so timed that both interlaces eliminate themselves  The result in resolution and color mixing would be great. Where can you get Deinterlacing devices?
10
« on: May 04, 2013, 09:20 AM »
Oh, I already had an idea how to use 128K in a VDC. That's why I wanted to get more I/O-Lines My idea based mostly on the idea to display more colors on the VDC without too many programming, but maybe something of this can be interesting to you. Actually there are VDC-FLI images, rather difficult to program. So I thought on realizing this in hardware. This would require four 4464 RAMs, 2x 64K for the VDC, and an oscillator for the alternating frequency. Using the RAM's Read/write Enable-lines it should be able to control the data access using an 8bit I/O-register. If the alternating frequency is high enough, the result would be a stable 128 color display even in text mode. But of course there's more possible, because every VDC register (including resoluions and X/Y position) will also be changed. This could create a lot of interesting effects. The new hardware functions are controlled by the user port. /o is a CIA 2 signal set to output (read/write), /i to input (read only). For the later description, the Datasheet of the 4464 is here. PB0/o - Toggle Bank 0/1 (switches between Bank 0 and 1, default is 0) PB1/o - Toggle Bank 0 output (sets 4464 G signal for Bank 0. I hope it will enable or disable the video output of this bank) PB2/o - Toggle Bank 1 output (like above for Bank 1) PB3/o - Toggle Bank 0 write (sets 4464 W signal for Bank 0. I hope it will be able to display one or two banks, but only writing to one) PB4/o - Toggle Bank 1 write (like above for Bank 1) PB5/o - Toggle Bank alternating mode PB6/i - Actual active RAM bank PB0 - I think this should be the easiest. PB0 sets the actual RAM bank, so it's possible to use two complete different VDC configurations. The state of the RAM bank will also be readable in PB6, so software could react on it. If alternating mode is disabled, the VDC will return to the bank set in PB0. PB1/PB2 - The 4464 has a G signal for enable/disable output, which is always activated on the C128. I hope it will possible to disable video output on the VDC by modifying this signal. In that case, it would be able to display a picture in alternating mode while loading a new image into another bank in the background. The bank with displays the image has to be set to write-disabled. Example: PB0 - 0 (bank 0 is displayed) PB1 - 1 (bank 0 is read-enabled) PB2 - 0 (bank 1 is read-disabled) PB3 - 0 (bank 0 is write-protected) PB4 - 1 (bank 1 is write-enabled) PB5 - 1 (alternating mode on) PB6 - X (actual bank) This config displays an image in the write protected bank 0, while bank 1 is write-enabled, but not shown. If PB6 is 1, the data could be written. Maybe this check isn't neccessary if the alternating frequency is high enough. PB3/PB4 - The W signal on the 4464 should enable write state. This could be used for the trick described above, but also for having a fixed background image and modifyable image in the other bank. Here's an example with a background image in bank 1: PB0 - 0 (bank 0 is used) PB1 - 1 (bank 0 is read-enabled) PB2 - 1 (bank 1 is read-enabled) PB3 - 1 (bank 0 is write-enabled) PB4 - 0 (bank 1 is write-disabled) PB5 - 1 (alternating mode on) PB6 - X (actual bank) if PB6=0 then bank 0 could be changed like usual, but still has a fixed background image in bank 1. Interesting: if the image in bank 0 is a movable object like a sprite and it will move over the picture of bank 1, the colors will be mixed. I'm not sure about the value of the alternating frequency. Should it only be to get a static image (50/60 Hz) the double (100/120 Hz) or the double frequency of the VDC (32 MHz)? If it's 32 MHz, the actual bank couldn't be checked by the software because the CIA is only works with 1 or 2 MHz. Well, if this bank alternating works, this trick could be used somewhere else. If the VDC signal is converted to RGB-Analog, it can't be converted not only to VGA, it's also S-Video and Composite possible. That would lead to the question: Why not alternating VDC and VIC? There are still some bits on the userport available. PB7/o - alternate VDC/VIC mode PA2/i - actual screen (0=VIC 1=VDC) The result could be fantastic: A 16- or 128-color VDC high-resolution bitmap combined with the advantages of the VIC. There's also more color mixing possible. And because the image mixing is done in hardware, it doesn't need extra CPU time. And, it's also possible to use these features from C64-mode. But it's not too easy: There would be again the question about the alternating frequency value, and it it's possible to alternate two S-Video signals with 100 or 120 Hz at all. It's also a question if PA2 could used as input signal without problems. For the software would be one main problem: VDC and VIC must be aligned correctly for mixing, it'll require a tool to calibrate the VDC x/y and size parameters with the VIC. This could be done by showing to similar pictures on VDC and VIC in alternating mode, and the VDC's position and size has to be moved until the images are matching as good as possible. The values must be stored in a file or best as default VDC register values in a patched ROM file, which has to be burned in an EPROM. I know the positions of the default VDC and VIC registers in the C128's ROM.
11
« on: May 04, 2013, 08:14 AM »
Well ok, but don't laugh  It started with an easy idea how to get more I/O lines into the C128 without using the user- or expansionport. It would have been C128 only-thing, so I thought of using the address room of U36 for it. There is no real interesting software for U36, and only a a few ROMs are using the full 32K, so a mix of I/O, a 16K ROM and RAM could be possible. If the the G65C22P-2 (VIA without shift register bug) in PLCC case would be used, the internal board could kept small. But beginning with small ideas like that, it lead to ideas which forced to lay awake the whole night. At the end it was the U36DS, or U36 development system. The board is a completely independent plug-in-board which sits between the most important chips of the C128. This would be at least VIC, VDC, SID and the CIA for keyboard and joystick. The data exchange will be done in the U36 adress room. A REU needs only a few bytes in the memory for efficient data exchange, so 32K should be more than enough. The board should be designed to soldered at home, so no SMD should be used. Also the other components should be used from existing computers, RAM is provided by old PS/2 SIMMs. These are the specs I had in mind: System: - system clock based on PAL or NTSC - CPU 65C816S with 14 MHz - bus clock about 28 MHz - 16 MB RAM - perhaps a REU emulation, again with 16 MB The CPU/system clock should be synced with the C128. The VIC-IIe has a clock signal of about 14.xx Mhz, maybe this can be used. The bus clock must be at least the double then. The 16 MB are for the 65816, a REU emulation with another 16 MB would not be bad, since the NUVIE videos we know how much these things can enhance our computers. If it is located in the U36 adress room, both computers would have access to it and could share data. Video: - Amiga Bit Fat Agnus 8375 (2 MB) - Amiga OCS Denise 8362 - Access to the C128's VIC-IIe - Access to the C128's VDC The old Amiga chipset isn't the newest anymore, but a truecolor Full-HD output in a retro computer would be a bit weird. The Amiga chipset has a lot of advantages: is easy to get; just rip off an A500 or A500+ and you have the chips. It is also fully register-programmable and well described. If the genlock function could be activated, it would be possible to mix the image with an external signal or internal with the VIC (remember: BASIC V10 of the C65 has a GENLOCK command!). It also has a RGB-Analog output with 15 KHz, the same as the VDC (with Richard42's signal converter). VIC and VDC can directly be used because they're plugged into the board. Audio: - Two 8580 SID's - Access to two C128 SID's - a high-quality audio chip with input - MIDI access - Possibly: two hardware MP3/WMA/OGG decoder - Possibly: a very good speech synthesizer For video is the Amiga's chipset good enough, but not for audio. The system should have very good audio hardware, so it will be interesting for musicians. Four MIDI-controllable SID's would be great. The main first two are 8580 SID's, they could only be used by the new system. For musicians is the 8580 a better choice. SID 3 and 4 are the ones from the C128, they should be able to be mixed. A HQ audio chip with HD streaming ability could lead to interesting multichannel trackers or even sequencers. The hardware decoder for compressed audio would be methods to save memory and CPU time. The MAS-Player on the Amiga allowed to play MP3's using the parallel port without CPU speed loss. There should be two, so it can be used in games for playing music and speech. The speech synthesizer chip would reduce the memory amount further, but it must have very good quality, so no Magic-Voice cardridge. Storage: - at least 3 SATA-ports - one or two SD-card slots - a programmable shugart-compatible floppy controller for four drives SATA is used for HD and optical drives. If the computer should be useable for audio, it must have HD streaming ability and it must be able to burn at least Audio-CDs. SATA drives are easier to get, and they use less space than PATA connectors. But it's possibly not too easy to find a suitable controller, and also the filesystem is a question. Normally it should be compatible to PC or a Mac (->FAT32), but will special file types like USR or REL work with it? Perhaps a modded CMD HD DOS could do the trick. The SD-cards are for data exchange. As floppy controller I would like to have a very flexible controller like in the Amiga, so it can read many formats by programming. The devices have fixed adresses: 20-21 HD, 22 DVD, 23-24 - SD, 25-28 Floppy. If the computer has access to the drives on the serial bus of the C128 (via the CIA), they can be used, too. Possibly it's neccessary to build the storage devices like a commodore drive, with own CPU, RAM and so. Input/Output: - PS/2 keyboard and mouse - two joystick inputs - access to C128 joystick - Ethernet - MIDI in/out/thru - Audio Line in - SID Audio in - Genlock Video in/out - Wacom Tablet Connector - a lot of I/O and equivalents to Userport and expansionport The most stuff is clear. PS/2-keyboards and -mice are easy to get. Volume and media keys should be supported. There's no special need to have a 1351 emulation, it's better to have full support for the wheel and multiple keys. The system should have two own joystick inputs, the C128's joysticks could be shared, so there would be four inputs. The Wacom Tablet connector is a special idea: It should be possible to connect serial Wacom graphic tablets on it. They are cheap and available in many sizes. The operating system should support them by directly, including pressure sensitivity and all four pen buttons (tip, 2x side, eraser). There's also another idea behind this: Many Tablet PC's, like the Lenovo x60t/x61t are using the Wacom Penabled system, which is very similar to serial Wacom Tablets. If it would be possible to use one of these screens, it could be possible to create a touch-sensitive 65xx-compatible computer. These displays have 12,1" size with 1024x768 pixel, ideal for RGB-Analog-2-VGA converters. Operating system: The typical things, a kernal, two character ROMs, a BASIC interpreter. And a kind of BIOS for default settings. The BIOS should be accessed by holding a key or so. It should use similar functions like on a PC, like setting the clock, selecting boot device and so on. Important is for me a keymap editor with default settings for layouts, so the keyboards can be personalized. Special keys like volume and Media control should be available. At the beginning the computer starts, like every classic Commodore computer, in the BASIC interpreter. But this time it's a complete 16 bit-BASIC. The 8 bit-Mode of the 65816 should never been used, maybe it's even possible to block the SEC/XCE command. There's are hardware output lines on the 65816 which are showing the status of the Emulation- and M/X-Flags. Some special things are neccessary: there must be a textmode emulation, the Amiga Chipset doesn't have one. There should be two charsets, one is identical to the Commodore PETSCII, the other one is an international ASCII font, perhaps the Amiga's Topaz font. Standard resolution is 640x200 in 16 colors and VDC palette. PAL resolutions (256/512 pixels height) must be supported, though. Three sprites will be used by default: one is for the mouse pointer, one is for the cursor. Using a sprite for the cursor would also allow more flexibility in font sizes. A third sprite is used for the Wacom Tablet pen. It must change form or color if the pointer is hovering over the tablet or if the tip is pressed onto the tablet. The ROM should combine stuff of the 8bit-Commodores and the Amiga, but it should contain f.e. things like localization routines, like the locale.library on the Amiga. These functions should also be available in BASIC. Well, that's so something I thought about. Maybe an nice idea to dream about (well, I laid a night awake), but it's not to expect that it will realized. Or will it? 
12
« on: May 03, 2013, 11:11 AM »
Have you started the computer with 40/80 key locked or unlocked? The text "BASIC V7.0" etc. and the READY cursor will only appear when this key is locked during startup. Do you have a custom ROM file in the internal function socket U36? What operating system are you using, the standard Commodore system, JiffyDOS or something else? It is also possible to switch between the displays pressing Esc, then X. Don't press the keys together, like for a use with CTRL. In Basic you can use POKE 215,0 to get to the 40-column screen and POKE 215,128 to the 80 column screen. The cursor color will switch to yellow on the VDC, don't ask me why
13
« on: May 03, 2013, 05:07 AM »
Check here again. The IBM drives seem to be Mishusbishi drives without Molex power connector, but with +5V on Pin 3.
14
« on: May 03, 2013, 05:04 AM »
I only know V1.34 and V1.40 for FD-2000 and FD-4000 seperately. The CMD HD BootROM has more versions, I know 2.52, 2.78 and 2.80.
15
« on: May 02, 2013, 06:04 AM »
There's no need to panic. In my two FD's both were 1.34 ROMs (2000 and 4000), I upgraded to 1.40 from a friend's FD-4000. The CMD HD also has several versions of the BootROM, the latest is 2.80. I didn't wanted to upload my ROMs official in the forum, don't know if Maurice would get mad. The FD-4000 ROM's are not even to find in Pokefinder.org!
16
« on: May 02, 2013, 05:15 AM »
It won't be a problem with the oscilltors. But thanks to your thread with a lot of FD-2000 pictures all official FD-2000 boards we showed yet had a silver oscillator and the white field on the board for the serial number, the FD-4000 boards have a black oscillator and no white field, like my two boards. So it was possible to notice that CMD used reworked FD-4000 boards sold in later FD-2000 drives.
I added the link to your thread at the first post of this thread now.
17
« on: May 02, 2013, 04:02 AM »
I found something on an german ... Atari ST (urk) site about ED drives. Here's the translation of the jumpers of the EPSON SMD340 drive: As you can see, Pin 3 is removed because some computers have problems with +5V on the Shugart bus. There are eight different jumpers, connected vertical. As marker has every second jumper a number on the PCB. The counting begins on the left with 1 and ends on the right with 8. Section A:14 - 15 DSO Drive Select 0 15 - 16 DS1 Drive Select 1
Section B: 6 - 7 DS2 Drive Select 2 7 - 8 DS3 Drive Select 3 Section C:
4 - 5 HDO automatic disk change 5 - 13 HDI HD-mode using HD-IN input Section D:1 - 2 HHI HD-IN input is high-active (HD - mode = +5V) 2 - 3 LHI HD-IN input is low-active (HD - mode = 0V) Section E is for testing and calibration purposes. So, that was it. I can't give any warranty if this is correct, I just translated it
18
« on: May 02, 2013, 02:16 AM »
Here are these IBM drives for 29 USD  Well, at least something is interesting. This drive looks like mine if you're comparing the front bezels (left one). If you check out the pictures, you can see on the top that the drive model starts with MF... , so it it could be possible that it's a Mitshubishi drive like mine. Perhaps you should ask the seller if you can get better photos of the drive, the sides are very important, there are the jumpers located. EDIT: I just got some information about the IBM drives. Two ED drives are listed: - Mitsubishi MF356F-815MB (a white 2.88MB drive), FRU 82G1888 - Mitsubishi MF356F-899MF (a " * " 2.88MB drive), FRU 64F4148 The drives seem to work with 5V only, and the Mini-Centronics connector is used on the external IBM disk drives. I have one, and the connector is on my docking station of my A31p. Now we have to check where the 5V are on the 34pin-Connector. According to this page, it is located on Pin 3. EDIT2: I've just checked on my Mitsubishi MF356C-252MG, Pin 3 and +5V are connected. But the CMD FD-4000* doesn't seem to provide power on Pin 3, if it's connected without power supply, the drive LED flickers a bit, but that's all. I've checked Pin 3 and +5V on the FD-4000 board, they are not connected. I don't have my board outside the drive now, but if anyone has it available (f.e. while soldering the 68pin PLCC socket), then it would be an idea to check out if Pin 3 of the floppy connector is connected to any other place on the board. If it's not used, it would be maybe the easiest way to solder a cable from +5V to Pin 3. In that case, a warning sticker should be placed on the case or the board that Pin 3 has +5V now. The other method would be an adapter or a modded cable with leads +5V to Pin 3 of the disk drive, but no in direction of the FD-2000/4000's board. And again, the cable or adapter should get a warning message. * Info: My boards are real FD-4000 boards because they have the black oscillator.
19
« on: May 01, 2013, 05:30 PM »
Yes, it's very interesting. The CPU runs mainly on 2 MHz and switches only sometimes to 4 MHz? Then it should be no problem that a reworked FD-2000 should work with the original 2 MHz 65C02/65SC02. I noticed no problems, and if the SuperCPU uses an overclocked 14 MHz 65C816S, 2 MHz more shouldn't be a problem. But anyway, I hope my Rockwell R65C02P4 will arrive soon to make the rework complete. Now it would still be interesting how this rework works on a real FD-2000 board with silver oscillator. Mine was a FD-4000 reworked to an FD-2000, noticeable on the black oscillator. See this thread for more information. Addon: It's really incredible. I had no problems to get all components so easy on ebay, floppy controller, RTC and even an ED drive. But now it seems the parts have dried out, I didn't found even a datasheet for the PC8477AV-1 floppy controller, only for B, BV or BV-1 types. Combined with the fact that I am actually the only FD owner with an FD-4000 board with two sockets, I must have had extreme luck to become an alpha tester for the FD rework.
20
« on: April 30, 2013, 07:11 AM »
Yes, there's also the F8-Assblaster for the Flash8. I always want to start with 65xxx-Assembler, but I don't find the time, and, like always, I would have to do this alone. My friends aren't so interested in experimenting and programming. But when I'm starting, then directly in C128 mode. @ Mirko: Could you test what happens with Krestage 3 on a real SuperCPU, in 8 and 16bit? It doesn't work on emulators because it uses very special VIC tricks. On the emulation of Deus Ex Machina it was very interesting that the first parts with graphics tricks including sound were in slow-motion in 16 bit mode. Krestage 3 also uses special graphic tricks, it would be interesting what happens. Testing the C128 demo Risen from Oblivion would also be interesting in 16 bit mode.
21
« on: April 30, 2013, 05:29 AM »
I'm testing some software on the emulated SuperCPU now and post them here. It's running at 1 MHz and in 16bit mode if not other described. If I should test something, tell me. Games:Bubble Bobble +8 by Remember: Works fine in 8 bit mode, doesn't reach the trainer menu in 16 bit mode. Turrican II: Loding the intro and cheat mode of a Turrican II release from 1581 worked. But the title screen (the intro wan't loaded) wasn't starting, distorted screen with text characters. Well, I made a reset - and then the fun began, weird graphic error animations, sound effects, always changing After some more resetting I only got one-colored screens and SID-scratching, then at last a VICE 65802/65816 CPU JAM! error. In 8 bit mode, the title screen was loaded, but not the game. Demos:Alternate States by Taboo (50% version): Crashes after the text note in 16 bit mode, runs fine in 8 bit mode. Biba 2 by Arise: Doesn't work in 8 or 16 bit mode on the emulated SuperCPU. Deus Ex Machina by Crest/Oxyron: Well, that was fun. In 8 bit mode there are some graphical issues during the intro and the FLI-picture at the beginning. In 16bit mode, all graphic-intense stuff is highly flickering and - it's in slow motion, also the sound! Maybe the 65816 needs more cycles in the 16 bit mode. In both modes stopped the demo after the 'Big Breadbox'-Logo, in 16 bit mode the demo stopped, in 8 bit mode it crashed with a CPU JAM! Krestage 3 by Crest: This was this demo which showed sprites with 50 pixel width and 9 sprites in one rasterline. But in 8 and 16 bit mode it showed a message: NO VIC INSIDE - This machine is not capable of displaying the VIC tricks of this demo. But on the normal VICE it wasn't working, too 
22
« on: April 30, 2013, 04:25 AM »
Hi, I want to give you some information about the 65C816 CPU used in the SuperCPU or Flash8. You know it's an 16 bit CPU with 8 bit emulation mode, it starts in 65C02 emulation mode. How will the modes will be changed? There's no direct command for it you have to do it indirect, using the Carry flag of the status register. Behind the Carry flag is a hidden Emulation flag, which has to be exchanged with the Carry flag. So it works like this: 1. Clear the Carry flag with CLC, CLear Carry - Opcode hex $18, dec 24 2. Exchange it with XCE, e Xchange Carry with Emulation - Opcode hex $FB, dec 251 That's it. To set it back, set the Carry Flag and do use XCE again. 1. Set the Carry flag with SEC, SEt Carry - Opcode hex $38, dec 56 2. Exchange it with XCE, e Xchange Carry with Emulation - Opcode hex $FB, dec 251 It is possible to use this on the C64 and C128 with SuperCPU, Flash8 and other 65C816-based accelerators. Here are the assembler commands in BASIC. The programs ends with an RTS (Opcode hex $60, dec 96), so it can return to the BASIC interpreter. Set to 16 bit mode: 10 POKE49152,24
20 POKE49153,251
30 POKE49154,96Use RUN to poke the data. After this start the program using SYS 49152. On the C128 you have to search a location useable for machine language programs. What happens: On the Flash8 in 1 MHz mode, I get a distorted screen (text characters) and the computer doesn't react anymore. In 8 MHz mode happens the same, sometimes I got a completely green screen. After a while the Turbo LED gets dark. On the emulated SuperCPU in VICE happens noting, but loading Metal Dust wasn't working. So, how to get back in 8 bit mode: 10 POKE49152,56
20 POKE49153,251
30 POKE49154,96And again RUN and SYS 49152. Because the Flash8 crashed as it was in 16 bit only, I tried to switch to 16 bit and immediately back to 8 bit: 10 POKE49152,24
20 POKE49153,251
30 POKE49154,56
40 POKE49155,251
50 POKE49156,96And again RUN and SYS 49152. This worked without problems on the Flash8. So the system is not dead, only the C64's kernal or the BASIC interpreter doesn't like the 16 bit mode. That's of course the most basic 65816 command you ever need. There's a lot more, the 65816 has like the Emulation-Flag to mode hidden flags. The unnused status register bit 6, which is always 1 on an 8bit 6502, contains the M-Flag, which allows to switch memory and accumulator size between 8 and 16 bits. Bit 5 is usually the BRK flag, it seems that it is replaced with the X flag, it can set the index registers to 8 or 16 bit size. The 65816 also has new registers: The Direct Page Register, the Data Bank Register and the Program Bank Register. So, this maybe a rather useless routine, but well, at least there's somewhat you can use the 16 bit-mode of your 65816 CPU Maybe someone has some ideas for little 65816 ML programs which could be typed in as BASIC commands. Because my Flash8 crahes with distorted screen when left in 16 bit mode, I would be interested in some text output. This would mean, a clear screen command and some text output. Pressing a key should return to 8 bit mode and quit to BASIC.
23
« on: April 29, 2013, 02:40 AM »
The user NLQ made an IEEE interface using an ATMEL µC. It needs extra 5V, will be connected to the serial bus and supports the JiffyDOS protocol. I can search if I find something about it.
24
« on: April 26, 2013, 05:39 AM »
I know that today's PCs have no disk drive anymore, but a lot of computers also don't have a real serial or parallel port which is neccessary for the X-Cable. USB-2-Parallel-adapters won't work. That's why I'm using my IBM Thinkpad A31p laptop. It's from 2003, so it has all real hardware connectors you'll need for retro computing. A disk drive can be connected in the laptop's left Ultrabay or as external drive on the docking station. However, all my Asus AMD Socket 939 based-PC's still have disk drives inbuilt. These are about from 2006, all have hardware-based serial and parallel ports. CPUs are up to 2.95 GHz Dual Core. But the copying speed with 1581disk is not depending on the CPU's speed, it is limited by the floppy controller. To compare: My Gigabyte Core i7 board which has no FD and IDE ports anymore, also no parallel port. A serial port exists, but only as connector on the mainboard, not external. Today's PC's are not made for retro computing  When it comes to transferring data, it shouldn't be done with the speed of 1 MHz. If there's a faster way, it should be used. That's why we are using speeders like JiffyDOS, Action Replay or parallel speeders on our Commodore floppies. Another tip, after the A31p: If you have an AMD Socket 939 CPU somewhere, check out the Asus A8N-SLI Premium. It's a very well equipped board with a lot of features, and all ports you'll need for retro computing. If you're installing an Asus U3S6 card, you'll get two additional USB 3.0 ports and two SATA 6 Gbit/s ports. The new SATA ports are bootable from the standard BIOS, they will be shown as SCSI-1 and SCSI-2 in the boot device list. I have at least four of these boards and I still like them, in comparison the the Gigabyte board for the Core i7 they are much better equipped (more and better organized PCI/PCI-E slots, firewire, gameport, parallel, more sata, ide, floppy). But I have to switch to Intel because I'm using OSx86 as standard operating system. Since OS X 10.7 Intel CPUs are neccessary because it needs the SSSE3 command set, AMD CPUs don't have it.
25
« on: April 26, 2013, 05:14 AM »
What, am I'm getting something wrong or takes it really 26 minutes for transferring an .d81 image to disk? These are the times for writing an .d81 image with 1581disk: Write to 1581-preformatted DD disk: 0:49 min
Write to unformatted DD disk: 1:37 min
Write to unformatted DD disk with verify: 2:08 min
Read 1581 disk to .d81 image: 0:49 min
A bit faster And there's no external hardware neccessary, just a standard PC or laptop with an internal floppy drive. 1581disk is on a PC the easiest way to exchange files to the C64/128. Create in VICE an empty 1581 disk image, mount it as a drive, load a file copy program (I'm using CMD's FCOPY because it supports 1581 partitions) and copy the files you need. After the image is finished, copy it with 1581disk to a real 1581 disk. Important is only, you'll need a computer with a real disk drive (no USB) and Windows XP, I'm not sure if Windows Vista or Windows 7 are still supporting floppy disk drives.
Pages: [1] 2 3 ... 5 Next
|
Show Posts
