Wires? Pah.....

discuss PC<>Acorn file transfer issues & the use of FDC, XFER, Omniflop/disk etc.
bogax
Posts: 5
Joined: Mon Feb 27, 2012 4:03 pm

Re: Wires? Pah.....

Postby bogax » Mon Feb 27, 2012 6:10 pm

I come here from this thread:

1Mhz 6502 bitbang 57kbaud (6502.org)

to comment re this code mentioned there:

Code: Select all

  720 LDY#0:LDA&FE60:ASLA:TYA:RORA:NOP
  730 TAY:LDA&FE60:ASLA:TYA:RORA:NOP:NOP
  740 TAY:LDA&FE60:ASLA:TYA:RORA:NOP
  750 TAY:LDA&FE60:ASLA:TYA:RORA:NOP:NOP
  760 TAY:LDA&FE60:ASLA:TYA:RORA:NOP
  770 TAY:LDA&FE60:ASLA:TYA:RORA:NOP:NOP
  780 TAY:LDA&FE60:ASLA:TYA:RORA:NOP
  790 TAY:LDA&FE60:ASLA:TYA:RORA
  800 STA BUF,X:JMP SB

from here http://www.stardot.org.uk/forums/viewtopic.php?p=32580#p32580

so a couple alternatives

Code: Select all

  720 LDA$#4F:CMP&FE60:ROR BUF,X:NOP:NOP
  730 CMP&FE60:ROR BUF,X:NOP:NOP
  740 CMP&FE60:ROR BUF,X:NOP:NOP
  750 CMP&FE60:ROR BUF,X:NOP:NOP
  760 CMP&FE60:ROR BUF,X:NOP:NOP
  770 CMP&FE60:ROR BUF,X:NOP:NOP
  780 CMP&FE60:ROR BUF,X:NOP:NOP
  790 CMP&FE60:ROR BUF,X:NOP:NOP:NOP
  800 JMP SB

OK, the timing isn't quite the same but maybe
close enough.
It doesn't use Y, the byte is inverted, there's less
jitter in the sampling and the last three NOPs maybe
unnecessary (leaving more time to do something else)
Page crossing in the buffer might have to be accounted for.

Here's a variant that doesn't have that problem but needs
a temp variable

Code: Select all

  720 LDA$#4F:CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  730 CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  740 CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  750 CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  760 CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  770 CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  780 CMP&FE60:ROR TEMP:NOP:NOP:NOP:NOP
  790 CMP&FE60:LDA TEMP:RORA:NOP
  800 STA BUF,X:JMP SB

But I think we dropped another cycle there.

Or, if there's no room for a zp temp one could go back to using y

Code: Select all

  720 LDY$#4F:CPY&FE60:RORA:NOP:NOP:NOP:NOP
  730 CPY&FE60:RORA:NOP:NOP:NOP:NOP:NOP
  740 CPY&FE60:RORA:NOP:NOP:NOP:NOP
  750 CPY&FE60:RORA:NOP:NOP:NOP:NOP:NOP
  760 CPY&FE60:RORA:NOP:NOP:NOP:NOP
  770 CPY&FE60:RORA:NOP:NOP:NOP:NOP:NOP
  780 CPY&FE60:RORA:NOP:NOP:NOP:NOP
  790 CPY&FE60:RORA:NOP:NOP
  800 STA BUF,X:JMP SB

but we're back to having some wobble in our sampling times.


Sorry if this is all redundant or out of date, haven't read
this whole thread yet.

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Tue Feb 28, 2012 12:03 am

Thanks very much for the input, all interest very welcome and thanks of course to Ed for the promotion :D

bogax wrote:Sorry if this is all redundant or out of date, haven't read this whole thread yet.
I probably have moved on a little but more significantly I have very carefully scope-tuned the timings of the current RS232 engine (Tx & Rx) to the last half-microsecond across several Beebs, Masters and Elks with many PC's. Whilst I therefore acknowledge that there are some potential variations on the theme, the final code has been tested to destruction over the recent weeks and months (thanks UPURS team :wink:) and the system now has a proven error rate of something better than 1 Bit per Gigabyte :D

Anyway, get on and build yourself a cable - new members to the UPURS club always welcome :wink:

User avatar
CMcDougall
Posts: 5622
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Wires? Pah.....

Postby CMcDougall » Wed Feb 29, 2012 2:12 pm

MartinB wrote:
Me wrote:& Acornsoft-JCB Digger (see if it handles the '?' char).
I've just tried it in BeebEm under a special version of UPCFS and it does load all the way through but then appears to perform a reset back to the standard Beeb start-up screen. Did you expect it not to load?
I'll try it on a real Beeb later.
Just tried the JCB uef under *TAPE in BeebEm and it does the same thing!

sorry for delay Martin mate, the version also in the 144menu driven .dsd's also does not work. Not tried the .uef version you tried, but the one on its own .ssd does, and also my own version from BITD.
Great work mate (+other)! Tried it the other week on BeebEm414, how did you know that I had Arcade Action on original tape BITD! Snake was the best!! 8)
Congrats on putting PAGEtoE00, that sorts alot, as even *TAPE on beeb/emuls don't even do that! =D>
I take it the 'ROMimages' in 5&6 is only for emulator, and would not work on real beeb? and if so where do i get a Hex Editor? (Notebook no worky :( )
How does it handle other 'pain in bottom' games, like one's that load <&E00 like Players JoeBlade1&2, Ocean Hunchback.
This is great for getting old 'tapes'/UEFs working again, all we need now is a *UPSLOW so can wait 10mins again to get the real feel of 1982 :lol:
Will have to try this on my real beeb/elk's some time, sure my old xFer51 cable will need hacked up again! :wink:
ImageImageImage

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Wed Feb 29, 2012 10:23 pm

Hi Col - I was in bonny Edinburgh Monday/Tuesday, I'll have to bob in to Dingley Dell one day :wink:
Col wrote:I take it the 'ROMimages' in 5&6 is only for emulator, and would not work on real beeb?
The emulator version of UPCFS is just a debugging tool for the 'real' version and I only posted it to show how the system looks in use. To run UEF's under emulation, I think it makes far more sense to load them directly and if you're thinking real Beeb then rom'd UEF's are probably a bit pointless :-k

There's a list of non-players on Paul's UPCFS page at his Acorn site but we haven't really started hacking the tricky rascals in any depth just yet, there's more good stuff to come first :wink:

Funnily enough, t'other Martin already suggested a slow-down! Actually, apart from reliving the good 'ol days (?), it would also have some technical value as I suspect an odd one or two loaders are failing because UPCFS is simply too fast for their interrupt-driven loaders :wink:

Anyway, watch this space Col as UPCFS etc. are about to move a little closer to your heart :D

User avatar
Arcadian
Posts: 2804
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: Wires? Pah.....

Postby Arcadian » Thu Mar 01, 2012 6:35 am

MartinB wrote:There's a list of non-players on Paul's UPCFS page

Excuse me - you wouldn't happen to know whether this one runs on UPURS, no? ;)
ClowningAround.jpg
(63.3 KiB) Downloaded 2777 times
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug NORTH (Manchester) (19-21 January 2018)
ABug SOUTH (Hampshire) (1-3 June 2018)

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Thu Mar 01, 2012 7:40 am

Wow, that looks like an awesome game :shock:

But yes, someting tells me it'll definitely run under UPURS :wink:

(When's it due out btw? :-k [-o< )

User avatar
Arcadian
Posts: 2804
Joined: Fri Nov 24, 2000 12:16 pm
Contact:

Re: Wires? Pah.....

Postby Arcadian » Thu Mar 01, 2012 7:56 am

You're asking the wrong person! ;)
For a "Complete BBC Games Archive" visit www.bbcmicro.co.uk

Image
ABug NORTH (Manchester) (19-21 January 2018)
ABug SOUTH (Hampshire) (1-3 June 2018)

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Thu Mar 01, 2012 9:04 pm

Lol - only just noticed :lol: =D>
Clowning Around.PNG
(123.17 KiB) Downloaded 2732 times

User avatar
Samwise
Posts: 1823
Joined: Mon Mar 14, 2005 9:13 pm
Contact:

Re: Wires? Pah.....

Postby Samwise » Thu Mar 01, 2012 9:11 pm

*rolls eyes*
#-o

:)

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Thu Mar 01, 2012 10:18 pm

Heh - It's my age Sam :D

...and Dave's heavy hint caught me on the hop :oops:. I mean, come on, gimme a break, I'm all about the Acorn stuff but my gaming side comes in fits and starts. (Although admittedly there's only been the start so far... #-o)

User avatar
Samwise
Posts: 1823
Joined: Mon Mar 14, 2005 9:13 pm
Contact:

Re: Wires? Pah.....

Postby Samwise » Thu Mar 01, 2012 10:55 pm

No heavy hints from me - I'd actually forgotten about this project completely, as it's buried in the forum somewhere.

I must confess to being somewhat amused that you seem to have worked quite hard to keep it quiet - avoiding a permanent wiki presence and only breaking cover to ask for some coding advice over at RS. Since then you've been featured in Retro Gamer magazine, and now have the packaging designed.

I'd hate to see how big a splash it would be if you tried to market it ... haha

Sam.

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Fri Mar 02, 2012 12:19 am

Coming soon to an Elk near you..... :D



Details to follow...... :wink:

CanonMan
Posts: 477
Joined: Fri Jul 15, 2011 8:41 am
Location: Cheshire

Re: Wires? Pah.....

Postby CanonMan » Fri Mar 02, 2012 9:57 am

Oooooh, looks promising :D

User avatar
danielj
Posts: 5346
Joined: Thu Oct 02, 2008 4:51 pm
Location: Manchester

Re: Wires? Pah.....

Postby danielj » Fri Mar 02, 2012 2:28 pm

MartinB wrote:Coming soon to an Elk near you..... :D



Details to follow...... :wink:


*clapclap*

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Fri Mar 02, 2012 3:08 pm

Thanks gents 8)

It does require a very minor and straightforward mod to the Plus 1 printer port in order to create a suitable realtime input line but this doesn't in any way affect the standard functionality of the Plus 1 or the printer port.

Just reviewing the connecting cable options :-k

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Wires? Pah.....

Postby davidb » Sat Mar 03, 2012 12:51 am

Looks good! =D>

I wondered how you'd done the connection when I saw the video, with no wires coming out of the cartridge itself. I suppose the parallel port is the obvious solution. #-o

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Sat Mar 03, 2012 12:03 pm

Thanks David :wink:

David wrote:I suppose the parallel port is the obvious solution #-o

Well, yes and no. It is indeed a parallel (printer) port but sadly not a bi-directional one like the Beeb's User Port. It has eight output-only data lines, an ACK (output) line and a BUSY (input) line. ACK only supports fast pulses and BUSY is only updated by a write to the main output lines. Thus, for time-critical bi-directional applications such as UPURS, the Elk printer port is, on the face of it, useless :(

However, the little passive rewiring mod I've implemented makes BUSY into a real-time input without affecting it's original function. This done, using the new BUSY input and a single latching output data line, UPURS has access to the minimal interface capability it needs :D

User avatar
CMcDougall
Posts: 5622
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Wires? Pah.....

Postby CMcDougall » Sat Mar 03, 2012 2:25 pm

MartinB wrote:Hi Col - I was in bonny Edinburgh Monday/Tuesday, I'll have to bob in to Dingley Dell one day

lol, Yea should oww said, if a kent yea were cummin, I wouddy baked a cake! :)
Just checked the YouTube link, and =D> splendid!

Yeah, I did think to myself 3hrs later why want 'romImages' on real machine, but then again, the user port could be dead! :shock:
Also the typo for Notebook, its NotePad #-o . What Hex editor do you use then buddy? :?

Great work mate, may need you to make me a cable, as not got resistors at hand :( how much roughly, PM details.

Cheers, Col. :wink:
ImageImageImage

User avatar
paulv
Posts: 3606
Joined: Tue Jan 25, 2011 6:37 pm
Location: Leicestershire
Contact:

Re: Wires? Pah.....

Postby paulv » Sat Mar 03, 2012 6:46 pm

@Col - I'm on cable making duties while Martin is on Elk duties. I'll PM you with details when I'm at my PC later..

Paul

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Sat Mar 03, 2012 11:47 pm

Thanks Paul :D

Colin - If it's only the Elk aspect that interests you, you might want to hang on until we've decided which way we're going with that. I'm pretty sure it'll be an adaptor for the existing UPURS cable but nothing's been finalised yet. The 'system' works great and will be released very soon but the wretched Elk's reluctance to be mated with always causes headaches ](*,)

Colin wrote:What Hex editor do you use then buddy?

My very most favouritest is HxD =D>

bogax
Posts: 5
Joined: Mon Feb 27, 2012 4:03 pm

Re: Wires? Pah.....

Postby bogax » Sun Mar 04, 2012 4:35 am

MartinB wrote:Thanks very much for the input, all interest very welcome and thanks of course to Ed for the promotion :D

bogax wrote:Sorry if this is all redundant or out of date, haven't read this whole thread yet.
I probably have moved on a little but more significantly I have very carefully scope-tuned the timings of the current RS232 engine (Tx & Rx) to the last half-microsecond across several Beebs, Masters and Elks with many PC's. Whilst I therefore acknowledge that there are some potential variations on the theme, the final code has been tested to destruction over the recent weeks and months (thanks UPURS team :wink:) and the system now has a proven error rate of something better than 1 Bit per Gigabyte :D

Anyway, get on and build yourself a cable - new members to the UPURS club always welcome :wink:

Oh, I agree. If it ain't broke, why fix it?

I'm innocent of the vagaries of Beeb timing but I was attempting to make
the code timing the same (except that I assumed 15 cycles would serve
as well as alternating 14 and 16)

The main "advantage" (if advantage it be) is inverting the bits as
they're received rather than spending an instruction later.

But by now you probably have piles of code that rely on the buffer being
inverted. ;)

I did read this somewhere :
"it's easy to be blase about a few extra instructions here and there but if the few extra instructions apply to each byte then for my reference transfer of one full side of an ssd, the few instructions are multiplied by over 200,000 and microseconds easily become seconds" :P

User avatar
CMcDougall
Posts: 5622
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Wires? Pah.....

Postby CMcDougall » Sun Mar 04, 2012 2:35 pm

Thanks Martin for info and Paul for PM =D> , I will hold on then for Elk 'fix', as it takes my beeb 15mins to blow a 16k eprom! My elk/s have to share a Plus1 & 'broken' DFS Plus3.
ImageImageImage

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Sun Mar 04, 2012 11:17 pm

Hello again :D

As they say on TV, in no particular order..... :wink:
bogax wrote:But by now you probably have piles of code that rely on the buffer being inverted. :wink:
Not particularly, there's just one EOR #$FF per byte when each is removed from the transient buffer.
and wrote:I did read this somewhere : [snip] "...the few instructions are multiplied by over 200,000 and microseconds easily become seconds" :P
To be fair, you're quoting that somewhat out of context. In that paragraph I specifically refer to my minor frame (the core RS232 byte receiver) and my major frame (the rest of the utility's function). In the case of the RS232 byte inversion falling into the major frame, that's 2 cycles (or 1us @ 2MHz) multiplied by 200k which equates to a mere 0.2s for one side of a disc. Lost in the noise.... :wink:

And then the tech stuff..... 8)

I've attached the code for the final RS232 Rx which has maybe changed a little but I think there are some aspects you are neglecting to take into account. (I have another version for compatibility with legacy ports which supports a >256 byte buffer and doesn't employ a Start Bit detection delay list but the key timing principle is the same.)

To remind us before I waffle on, 115200 Baud = 8.68us (~17 cycles) bit width, 10 bits per byte with 'No Parity' and whatever code we use, we cannot proceed any faster than the 86.8us that is required to Tx/Rx one byte at 115k Baud.

At 2MHz, the Beeb's interrupt latency is greater than a bit width and therefore we have to poll each byte for the Start Bit (SB). Using the fastest possible method (including a delay list to detect a <Break>), this polling has a potential variable latency of between 7 and 11 cycles. The pre-receive code which has to dynamically monitor buffer fill and respond with CTS must have equal paths through regardless of whether CTS is reset or not. (Remember that the receive routine and its CTS control has to cater for transmitter overruns, likely to be between 1 and 5 bytes.)
This code expends 15 cycles and therefore, with our SB latency, we will read b0 of the byte at somewhere between 22 and 26 cycles after receipt of the SB. In fact, due to variations in edge-detection response by the 6522, I sometimes see 27 or even 28 cycles.

The significance of the above is that we cannot gurantee the point at which we will sample b0 and, because 2MHz does not produce a cycle resolution that equates precisely to 115k Baud, we either gain or lose time every bit if we use a subsequent fixed sample interval. A fixed 17 cycles would retard our sample point by ~0.2us per bit, 16 cycles would retard by ~0.7us per bit and 18 cycles would advance by ~0.3us. There are potentially 7 further bits to sample per byte giving rise to potential sample point shifts of approximately -5us, -1.5us or +2us. Hopefully you can see that none of these is acceptable as a fixed interval when we we have such a range of potential SB detection latency because the cumulative error could easily (and does :wink:) cause a slip into a neighbouring bit. This is the reason I jitter the sample point for b1-b7 and if you calculate the summation of the sample point offests, you will see that the SB detect latency is adequately catered for by jittering between 16 & 18 cycles.
and wrote:Oh, I agree. If it ain't broke, why fix it?
I hate that expression, it somehow implies that something works but isn't all it could be :(. Hopefully the above helps to show that there's nothing to fix :D

I know, I know, you'll be back....... :wink:

EDIT : Extra bit of info which may be causing you some confusion. A read or write to the User Port causes the clock to slow to 1MHz and I originally dived in without thinking assuming this meant that these instructions would therefore double-up from 4 to 8 cycles. However, only two of the four cycles are extended (the ram fetches stay at 2MHz) and so the total time extends from 4 to 6 cycles. Obvious when you think about it :roll:

RS232 Rx.zip
(729 Bytes) Downloaded 144 times

bogax
Posts: 5
Joined: Mon Feb 27, 2012 4:03 pm

Re: Wires? Pah.....

Postby bogax » Mon Mar 05, 2012 2:41 am

MartinB wrote:The significance of the above is that we cannot gurantee the point at which we will sample b0 and, because 2MHz does not produce a cycle resolution that equates precisely to 115k Baud, we either gain or lose time every bit if we use a subsequent fixed sample interval. A fixed 17 cycles would retard our sample point by ~0.2us per bit, 16 cycles would retard by ~0.7us per bit and 18 cycles would advance by ~0.3us. There are potentially 7 further bits to sample per byte giving rise to potential sample point shifts of approximately -5us, -1.5us or +2us. Hopefully you can see that none of these is acceptable as a fixed interval when we we have such a range of potential SB detection latency because the cumulative error could easily (and does :wink:) cause a slip into a neighbouring bit. This is the reason I jitter the sample point for b1-b7 and if you calculate the summation of the sample point offests, you will see that the SB detect latency is adequately catered for by jittering between 16 & 18 cycles.

By that reckoning you lose ~.4 us every 2 bits, cumulatively almost as much as the fixed 17 cycles over 7 bits.
It would seem varying between 17 and 18 would get you closer to what you want.

MartinB wrote:
and wrote:Oh, I agree. If it ain't broke, why fix it?
I hate that expression, it somehow implies that something works but isn't all it could be :(. Hopefully the above helps to show that there's nothing to fix :D

I just meant I know there's nothing to fix and I'm not trying to suggest that there is.

MartinB wrote:EDIT : Extra bit of info which may be causing you some confusion. A read or write to the User Port causes the clock to slow to 1MHz and I originally dived in without thinking assuming this meant that these instructions would therefore double-up from 4 to 8 cycles. However, only two of the four cycles are extended (the ram fetches stay at 2MHz) and so the total time extends from 4 to 6 cycles. Obvious when you think about it :roll:

I assumed something like that (and I think you discussed it earlier in this thread)

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Mon Mar 05, 2012 7:16 am

bogax wrote:I assumed something like that (and I think you discussed it earlier in this thread)
Apologies - I knew I meant to mention it but couldn't remember if I had. This particular quirk threw me for ages and I only eventually figured it out when I saw it on the scope #-o
and wrote:By that reckoning you lose ~.4 us every 2 bits, cumulatively almost as much as the fixed 17 cycles over 7 bits.
It would seem varying between 17 and 18 would get you closer to what you want.
The pads apply pre-b1 to pre-b7 and for a 16/18 cycle jitter (using four short & three long) we net +0.76us, for a fixed 17 we net +1.26us and for a 17/18 jitter we net +1.32us. Thus, the 16/18 jitter I'm using is the closest.

I did spend hours on a scope tuning this and I also ran prolonged transfer tests using a 'sliding window' across the range of theoretical values to identify where bit errors appear and disappear. The 16/18 jitter is both the theoretical 'best fit' but also the timing scheme that proved to be error-free across multiple permutations of PC & Acorn hardware.

Apologies if it sounds like I'm being defensive for the sake of it, I'm honestly not and I do genuinely welcome your interest and second pair of eyes 8)

User avatar
CMcDougall
Posts: 5622
Joined: Wed Feb 02, 2005 3:13 pm
Location: Shadow in a Valley of Scotland

Re: Wires? Pah.....

Postby CMcDougall » Tue Mar 06, 2012 1:41 pm

Just had a brain wave when thinking why the hell Repton's don't work on UPCFS (checked the list on other linky), its maybe the same as my SuperMMC card, some games have *TAPE put in the loaders, so could try editing the .UEF file with the Editor (very handy proggy, splits 16Ks aswell!) and changing the '*' TAPE to 'F4' so that its just a REM statement 8)
I also tried Yie-Ar Kung Fu1, but its a '?Data,rewind tape' error, and Yie-Ar Kung Fu2 just hangs after 'Please Wait...'
Can you change the emulator rom version, so that it can load from Ram banks 0-7? Then can try bigger proggys 8)

Cheers, Col :wink:
ImageImageImage

User avatar
davidb
Posts: 1901
Joined: Sun Nov 11, 2007 10:11 pm
Contact:

Re: Wires? Pah.....

Postby davidb » Tue Mar 06, 2012 5:27 pm

CMcDougall wrote:Just had a brain wave when thinking why the hell Repton's don't work on UPCFS (checked the list on other linky), its maybe the same as my SuperMMC card, some games have *TAPE put in the loaders, so could try editing the .UEF file with the Editor (very handy proggy, splits 16Ks aswell!) and changing the '*' TAPE to 'F4' so that its just a REM statement 8)


I assumed that some trickery had been done to trap *TAPE commands, otherwise I would have thought the success rate would have been quite low for UPCFS. I could be wrong, of course...

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Tue Mar 06, 2012 5:50 pm

David wrote:I assumed that some trickery had been done to trap *TAPE commands, otherwise I would have thought the success rate would have been quite low for UPCFS. I could be wrong, of course...
No sir, you are not wrong :wink:. There is an OSBYTE trap to discard *TAPE requests. Indeed, we don't want at this stage to do any UEF modifying although we may eventually look at UPCFS bespoke versions of sought-after programs.

(Worth noting though that many programs reset all the vectors at initialisation and if they do this, UPCFS will fall over for many reasons. This is one vulnerability that can't be defended against :()

Colin wrote:Can you change the emulator rom version, so that it can load from Ram banks 0-7? Then can try bigger proggys 8)
I dare say that can be accommodated, leave it with me :wink:

User avatar
andyt31
Posts: 300
Joined: Wed Nov 21, 2007 1:16 pm
Location: Peterborough, UK
Contact:

Re: Wires? Pah.....

Postby andyt31 » Wed Mar 07, 2012 1:05 pm

Loving UPURS 5.0 - thanks guys.

I should have it up and running at the Beeb@30 event at the end of the month. Ive even printed a proper label for the EPROM.

Image
IFEL Master ROM/RAM by Andys Retro Computers, on Flickr
Website : https://www.retrocomputers.online
Twitter : http://twitter.com/andytuk
Volunteer for The Centre for Computing History

User avatar
MartinB
Posts: 4555
Joined: Mon Mar 31, 2008 9:04 pm
Location: Obscurity

Re: Wires? Pah.....

Postby MartinB » Wed Mar 07, 2012 11:12 pm

Thanks Andy - your continued feedback and support is always much appreciated :D

Colin wrote:Can you change the emulator rom version, so that it can load from Ram banks 0-7? Then can try bigger proggys 8)
Here you go Colin, as requested :wink:

UPURS5dot1REM.zip
(5.39 KiB) Downloaded 148 times


Return to “software & utilities for the pc, mac or unix”

Who is online

Users browsing this forum: No registered users and 1 guest