MrMartian

I've sent my changes upstream, so hopefully they're incorporated, and there is no 'version with my changes'...

My comment regarding the command line, is that they put it on a normal digital pin, and enable the pin change interrupt on it. This causes an interrupt when it goes low and when it goes high.. If instead they had routed it to one of the defined INTx pins, it could be configured to only interrupt when going low. It would just save some code determining the state of the command signal in the interrupt handler.. Also, the INT0 pin is beside the TxD pin, so the wires would have gone to three adjacent pins, instead of the one spread across the board. <shrug> Also, as much as I'm very familiar with the ATMega itself, this project has made me look at the Arduino platform.. And, I see something I don't like for this use. The serial port on the ATMega32 is also connected to the onboard ATMega16U2 which is used for programming the board over USB. But, this means there is *another* device connected to those two pins (RxD, TxD) that can cause problems. Perhaps this is why some UNO boards are working fine, and others not, depending on how those lines are being handled when no programming. For reference, I use the "Elegoo UNO R3 Board ATmega328P ATMEGA16U2 with USB Cable for Arduino" board from Amazon and have no problems. I'm investigating how the boot loaders work on these boards, as this could also cause all the problems!

I can understand that... Not to take anything away from the work that's been done to get it this far, but the code could use a real good cleanup... Also, I'm curious about the choice of pin for the command signal.. Moving it to another pin would make some programming easier.

Here is the diff: diff --git a/SDrive.c b/SDrive.c index 0590906..7b28795 100644 --- a/SDrive.c +++ b/SDrive.c @@ -374,6 +374,9 @@ int main(void) CMD_PORTREG |= 1 << CMD_PIN; // with pullup CMD_DDR &= ~(1 << CMD_PIN); // to input + // enable port D pin pull-ups + PORTD = 0xFF; + //interrupts PCICR = (1<<PCIE1); PCMSK1 = (1<<PCINT13); // for CMD_PIN @@ -746,6 +749,7 @@ ISR(PCINT1_vect) cmd_buf.cmd = 0; //clear cmd to allow read from atari process_command(); + UCSR0B = (1<<RXEN0); // turn off transmitter LED_GREEN_OFF(virtual_drive_number); // LED OFF vp = FileInfo.vDisk; //save actual vDisk pointer diff --git a/usart.c b/usart.c index 7d2927d..d33895c 100644 --- a/usart.c +++ b/usart.c @@ -65,7 +65,7 @@ void USART_Init ( u16 value ) { //UCSRA = (1<<UDRE); /* Enable Receiver and Transmitter */ - UCSRB = (1<<RXEN)|(1<<TXEN); + UCSRB = (1<<RXEN); //|(1<<TXEN); /* Set frame format: 8data, 1stop bit */ UCSRC = (1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); { @@ -75,6 +75,8 @@ void USART_Init ( u16 value ) { } void USART_Transmit_Byte( unsigned char data ) { + /* enable transmitter now */ + UCSRB = (1<<RXEN)|(1<<TXEN); /* Wait for empty transmit buffer */ while ( !( UCSRA & (1<<UDRE)) ) ; And the .hex files to program: Edit: The .hex files are based on the v10 branch, but the patch works on any version... sdrive-nodiode.zip

Basically yes, this doesn't affect any timing of anything whatsoever. It enabled the USART tx pin as soon as the first byte needs to transmit, and then off again as soon as it's done processing a command. This evening when I'm home I will have time to post the changes, and I will upload the .hex files it created. Then lots of people can try running it. You can even leave the diode in place to test this as it won't affect anything. But, going forward, no one will need to add the diode / have any issues with the proper value. Not having the diode at all means no worrying about voltage drop, etc.

Sneak a few more minutes in tonight.. I didn't mean to be a tease.. The diode is basically there to allow a 'wire-or' method of sharing the wire, only allowing the device to pull the line low and using the pull up resistor in the Atari to keep it high. The ATMega32 chip can configure the pin used as serial transmit to be different functions, so all I did was change it so that normally it's an input not driving the pin high or low, but when it needs to send data it turns the pin to serial transmitter until it's done and then back to an input... I'll clean up the code, and post a git diff tomorrow and figure out how to send it back.. I'm more of a mercurial guy than git.....

Hey, I've been trying to find the time to write it all up, but just wanted to say it's a fairly small software change to make the diodes unnecessary... I have tested this with all my drives (810, 1050, Indus, Rana, Trak) and it works great.. Hopefully tomorrow I can write it up. It's probably less that 5 lines total changed...

Yeah, that's in the plans now. Big buffer!

Okay, that's probably to be expected.. I was pretty harsh with cutting things out to make more room, and I couldn't even test CP/M to know if it worked after. Now that I can, I may revisit my code and see if I can make it do ultraspeed and still be compatible with everything else.. So, yes, CP/M does work for me now. The problem was with SpartaDOS X's keyboard buffer (KEY ON) evidently causing problems with all of these programs (TT and the original programs). Doing a KEY OFF first makes it all better. So, thanks everyone for the helpful suggestions. Back to ROM hacking for me!

Is that my enhanced 1.2 Indus ROM? I wasn't sure if CP/M would still work with that, so I put the plain 1.2 back in..

Okay, so looking at the Indus RAM Charger Utility Disk.atr image, it's blank after the first many tracks so perhaps the copier software is being intelligent and not copying blank sectors... What I'm doing: - copying Indus RAM Charger Utility Disk.atr to a blank disk. - running cpmtool to fix the first three sectors - holding Drive Type and pressing Error - the disk spins, seeks to track one, and then the "INDUS CPM 2.2...." message appears on the screen.. Pressing return does nothing.....

I did, and did it again. So then I tried to re-do the sector copy and I think that's where it's failing.. This time I noticed it only writes a few tracks to the disk and stops... What sector copier have others used??

I'll post this here... a) I received my board, installed it, tests show all is good b) booting CPM, no matter which terminal I use (tt05 from trub, e.com or f.com), once I boot the CPM disk I get the 'Indus CPM 2.2 Rev 1.1, Hit return to continue' prompt but nothing I type does anything.... Am I missing something else? I'm using an Incognito 800, with the programs loaded from SDX. Thanks!

And since this was dragged up from the past, are there instructions around for a DIY Happy 1050 board? I have lots of processors, EPROMs and RAMs, but not a lot of money to spend on toys..

Yes you can. They are the same.

I just want to say that I have an 800XL here showing the same symptoms.. Changing RAM made no difference, changing MMU did - for about 10 minutes and now it's back to the same. I've swapped out all ICs, they work in another board but not in this one. I've replaced some sockets and still nothing.. May be similar problem, I'm not sure where else to check..

I would like one as well

64k chips, so 48k board, possibly 52k..

Why didn't we hear from more people back then when we wrote it?

As a side topic, all the ultraspeed ROMs I've made for the various drives, always include the 'f' command if anyone wants to play on them.

Generally, since all Atari devices that run on 9v AC rectify that and then generate their own DC, you can power them all from one 9v AC transformer, as long as it can supply enough current. There shouldn't be any problems with ground loops, etc, as all the DC 0v lines are tied together anyways. I run my 800, and a whichever disc drive I have plugged in that week, off a single transformer. Works great!

Not around here for months and months, and then I see wonderful new things like this! I'd like one please.

I would like one of these, if I can still get on the list..

Read back through this thread, I made an US Doubler compatible rom upgrade for the Indus drives... If you want the 'Happy' part for copying disks, no... And I don't think it would be too easy...

Be careful, I'm pretty sure I've seen you use 6502C and 65C02.. They are also very different chips...