hoglet wrote:Does it work then?
Has your board arrived Dave?
hoglet wrote:Does it work then?
Yes indeed, it arrived this morning. They look really nice boards. Thanks for taking all this on!sixxdog_uk wrote: Has your board arrived Dave?
Yes after finding the male connector not female, I lost thought for a micro second , so thats another 1:30 hrs to unsolder thoseMartinB wrote: Colin - you haven't soldered either of those 20-ways User Port connectors have you? .
Should have looked at the picture hereMartinB wrote:*** Alert! ***
Colin - you haven't soldered either of those 20-ways User Port connectors have you? They go on the opposite side to the components - unusual I know but it was all about the tracking conundrums...
Yes, of course the RAM or ROM or EPROM or EEPROM will still work - as long as you pray to the Flux Capacitor Mecca first before powering it upsixxdog_uk wrote:MartinB wrote:I of course have never made that schoolboy error...
You were also going to tell folk to replace D3 with a link and lose D4 & R4...?
I did mention it in the parts list sheet that I've sent out with them.
I included them in the parts in case people wanted to play about with the battery feature but i did say its now been superseded by EEPROM
I'm assuming the boards will still work with d3 in place a not a link? , also with d4 and r4 in place? Just a few extra pence on parts.
MartinB wrote:But, just to be clear for everyone on the other issue, the connectors must go on the non-component side, they are electrically reversed if not. Colin will have to move his....
MartinB wrote:Looks ok to me...
( Other connector types are available. )
roland wrote:Just a question .... what is IC 8 (not mounted in the pictures) intended for?
It's a "spare" position included in case any extra logic gates are needed. So far, it has only been needed for some boards fitted with SRAM when used with a Plus 1 that does not co-operate...roland wrote:Just a question .... what is IC 8 (not mounted in the pictures) intended for?
Heh heh, that almost sounded like an apology...roland wrote:I didn't buy this board only for UPURS, but also for connecting a MMC interface to it. After all, it has also a user port on it.
Yes, it's a known 'issue' (I think I prefer design quirk ) in the sense that the logic I've used for maintaining a constant 1MHz clock does knowingly allow glitches through to the 6522 but in extensive testing, none of the numerous VIA chips I tried ever acted on one of these glitches. Although I don't use MMC, I did test a basic unit, I think possibly one of Martin Mather's original designs (?) together with a range of other User Port-based peripherals and all worked absolutely fine. The additional focus for me from a personal perspective was UPURS and later I2C and again, these both work perfectly with EUP.Dave wrote:According to Martin this a known issue
Hmm, I might have spoken too soon.hoglet wrote: That said, so far MMFS has been working flawlessly, and others report the same. i.e. there doesn't seem to be any effect on the signals to the SD card. So at the moment this is of academic interest only.
UPURS is obviously just my name for the transfer system as a whole as isn't a protocol in itself, the actual technical detail going on behind the scenes (as I'm sure you know) is bit-banging 115k RS232 through a 6522 data line with another data line for handshaking and then all doubled-up to give the half-duplex link. So, because RS232 is asynchronous, the criticality comes with the RS232 bit periods for each 10 bits of data (one start, one stop, no parity) and these need to be kept close to 8.7us (which is why I have to use some cycle jittering) with any errors soon accumulating across the bits causing things to quickly fall over. So, the timing begins with the expending of instruction cycles in the UPURS code but the 6522 must then promptly 'clock' when the next bit is written and the whole process is predicated on either 1 or 2 MHz operation with the code being written accordingly. I don't use the CBn (or CAn) lines, just the PBn (or PAn) data lines.Martin, is UPURS operation dependent on the 6522 being clocked at 1MHz all the time? It seems to work find with the above mod in place.
Yes, it should not affect the rate that the 6522 data lines can be toggled.MartinB wrote: I cant't quite visualise what the mod is doing off the top of my head (being slow, busy day) but whatever effect it has, I assume that the UPURS software can still toggle the 6522 data lines at 1MHz so as not to impact the RS232 bit timing? I'm not sure if that that has fully answered your question....?
I created a disk containing 12 copies of BBC Basic, and have successfully transferred it back and to a couple of times, MD5umming the result each time. It's definitely working without errors.MartinB wrote: Incidentally, to check the operation of UPURS properly, you really need to transfer a full SSD from the PC to a target machine DFS floppy using UPSSD, transfer it back to the PC with UPXSSD and then carry out a binary compare of the source and transferred images. Repeat several times! This is the only way to be 100% confident that no single-bit errors are occurring.
Roland, I'll be very interested to see whether you have any issues with the SD Card interface.roland wrote: Question: I didn't buy this board only for UPURS, but also for connecting a MMC interface to it. After all, it has also a user port on it. I want to program both the UPURS and a DFS in a 32k EEPROM. Will that work or can I expect some issues with that setup?
Yes, I think this is possibly why - UPURS as a package is definitely not tolerant of clock variation because the RS232 bit timing tolerance at 115k baud is tiny, but I think that what I hadn't twigged to was that by necessarily restricting Elk UPURS to rom, both the code and the 6502 are being driven by a stable clock during a data burst so actually, the clock adjuster isn't needed. It is only of value where the 6522 timers are being used, for example as per the tests I wrote about on the original thread.I wrote:Edit thought : I had to stipulate that UPURS must run in rom on an Elk to insulate the bit-bang engine from the Elk's variable clock throttling but in doing so, had I actually unwittingly made the code inherently immune to the 6522 clocking? If so, that would explain why your 'clocking' the VIA with phi might work and would imply that the 1MHz maintenance logic isn't needed for any rom-based 6522 access, only for code running from ram that assumes a 1MHz 6522 clock?
At the moment I'm very busy with lots of things, so it will take a while before I build this interface. I'm not sure which FS I'm going to use. MMC on the Elk is completely new for me. Of course, I'll keep you informed when I have made some progress.hoglet wrote: Roland, I'll be very interested to see whether you have any issues with the SD Card interface.
Are you planning to use MMFS?