TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

discussion of beeb/electron applications, languages, utils and educational s/w
User avatar
sweh
Posts: 2131
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by sweh » Mon Jan 04, 2016 11:47 pm

Based on some testing I did with the matchbox CoPro and TurboMMC I think I may have found an issue with OSWORD 7F routines. I did the same test with Smart SPI and got identical results. So it's possible this error has been there since the early MM code days...

Here is my test code:

Code: Select all

   10DIM BLOCK% 100
   20D%=&2000
   30?BLOCK%=0
   40BLOCK%!1=D%
   50BLOCK%?5=3
   60BLOCK%?6=&53 : REM READ SECTOR
   70BLOCK%?7=0   : REM TRACK
   80BLOCK%?8=0   : REM SECTOR
   90BLOCK%?9=&22 : REM TWO SECTORS
  100X%=BLOCK%
  110Y%=X%/256
  120A%=127
  130CALL &FFF1
Now if I run this on a non-copro Beeb (*FX151 230 6) it works correctly. The first 2 sectors are loaded into &2000

If I turn the CoPro on (*FX151 230 1) and run it... the data loads at &130A instead. In testing with TurboMMC, and using BeebEm for comparison:
1) BeebEm no CoPro: works
2) BeebEm with 65C02 CoPro: works
3) BBC B with no CoPro and TurboMMC: works
4) BBC B with Matchbox CoPro and TurboMMC: loads at &130A
5) Master with no CoPro and TurboMMC: works
6) Master with John Kortink's internal 65C102 and TurboMMC: loads at &130A

(in fact there were two BBC B's; one issue 4, one issue 7, both the same results).

It doesn't matter what I set D% to, it always loads at 130A which makes me wonder if the OSWORD 7F routine is corrupting the address value somewhere.

I was told SmartSPI also worked with TurboMMC (it seems to!), so I tested that (tests 3 and 4)... exactly the same results. The sectors are loaded at &130A. This makes me think there might be a problem with the code going all the way back to Martin's original routines.

This normally has no impact (it seems to require OSWORD 7F and a copro to exercise it) so I'm not too surprised it hasn't been seen before. The Z80 copro uses it to try and load CPM, which is where I saw it.

Can anyone else verify this? Is my code just bad and wrong (it works on BeebEm...) or is there a bug?

Duikkie? Dunno if you're in a position to test/verify...
Rgds
Stephen

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Tue Jan 05, 2016 8:06 am

Stephen,

It would be interesting to try the same test with MMFS, which is derived from a more recent 2.xx version of DFS.

I can try that today.

Dave

User avatar
tricky
Posts: 4017
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by tricky » Tue Jan 05, 2016 8:42 am

Perhaps Tom could add SPI support to beebem, he has MMC, but I don't think it does it through SPI, that would make debugging easier.

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Tue Jan 05, 2016 12:39 pm

hoglet wrote: It would be interesting to try the same test with MMFS, which is derived from a more recent 2.xx version of DFS.

I can try that today.
It seems a similar bug also exists in MMFS.

What I observe is that the tube transfer address is incorrect, and in my case seems to be defaulting to that of the last loaded program.

For example, if do the following:

Code: Select all

LOAD "OS7FTST"
RUN
OS7FTST (your test program) gets clobbered by and you end up with a Bad Program.

However, if I do:

Code: Select all

LOAD "OS7FTST"
*LOAD OS7FTST 2000
RUN
Then OS7FTST actually loads sectors 0 and 1 to &2000 and &2100.

I've got the ICE-T65 debugger available in BeebFPGA (on the Altera DE1) with a 65C02 Co Pro, so I should be able to single step through MMFS and see where it's going wrong.

Dave

User avatar
jgharston
Posts: 3839
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by jgharston » Tue Jan 05, 2016 1:39 pm

Is the source code available anywhere?

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

User avatar
sweh
Posts: 2131
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by sweh » Tue Jan 05, 2016 2:13 pm

jgharston wrote:Is the source code available anywhere?
viewtopic.php?f=3&t=10526&p=127672&hilit=mmfs#p127672
Rgds
Stephen

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Tue Jan 05, 2016 2:21 pm

Right, I've tracked down the bug in MMFS and fixed it in version 1.06:
https://github.com/hoglet67/BeebFpga/co ... 8a6f6bdb6e

With this fix, I Stephen's test program works, and I can boot CP/M from the MMC Card from two .ssd images loaded into drives 0 and 2:

Code: Select all

*FX151 230 1
<break>
(that should take you to the Z80 * prompt)
*DIN 0 16
*DIN 2 17
*CPM
Here's the Master 128 build of MMFS 1.06:
MAMMFS_1_06.zip
(9.52 KiB) Downloaded 46 times
The bug that MMC_BEGIN2 was being called before CopyVarsB0BA, where as it needs to be called after, so that the load address is in &BC, &BD. It would be interesting to check if the same code is present in SmartSPI and TurboMMC.

Dave
Last edited by hoglet on Tue Jan 05, 2016 2:28 pm, edited 2 times in total.

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Tue Jan 05, 2016 2:26 pm

jgharston wrote:Is the source code available anywhere?
This is now fixed, at least in MMFS:
https://github.com/hoglet67/BeebFpga/co ... 8a6f6bdb6e

Dave

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Fri Jan 08, 2016 8:56 am

i will look if i can locate the error in my smart SPI rom :) , but i have only a bbc iss 4 board , no copro or anything else ( the SMART USB is hanging on the tube :shock:

i i heard from bill gate that i was telling all that SMART SPI was out of day , no update anymore :lol:

User avatar
Lardo Boffin
Posts: 1831
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by Lardo Boffin » Mon Jan 11, 2016 2:43 pm

Hello all

I have tried to download the updated MMFSM ROM but without much success! I managed to find a file mm-fsm.rom on the link in this topic but it killed BeebEm when I tried it there and also killed my Beeb (flashing cursor and nothing else after reboot) when I loaded it into sideways RAM and then did a control-break.
At the risk if sounding like a 'numpty' where is the correct download file or could some kind person attach it to a message in this topic please? It is for a model B.

I also tried the one 'MAMMFS' just in case but that also kills it.

Many thanks

Lardo
Atom, issue 5
Elk
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

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

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by danielj » Mon Jan 11, 2016 2:54 pm

That's the master build - does it work on the beeb?

d.

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Mon Jan 11, 2016 2:55 pm

Lardo Boffin wrote: At the risk if sounding like a 'numpty' where is the correct download file or could some kind person attach it to a message in this topic please? It is for a model B.
The version attached four posts up is actually the Master 128 version and won't work on the model B (hence the MA prefix to MMFS, sorry slightly obscure....)

I've just built you the Model B version:
MMFS_1_07.zip
(10.69 KiB) Downloaded 47 times
I've not tested it, because I'm a bit in the middle of something else, but give it a go.

Dave

User avatar
DutchAcorn
Posts: 2162
Joined: Fri Mar 21, 2014 9:56 am
Location: Maarn, Netherlands
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by DutchAcorn » Mon Jan 11, 2016 3:57 pm

hoglet wrote:
Lardo Boffin wrote: At the risk if sounding like a 'numpty' where is the correct download file or could some kind person attach it to a message in this topic please? It is for a model B.
The version attached four posts up is actually the Master 128 version and won't work on the model B (hence the MA prefix to MMFS, sorry slightly obscure....)

I've just built you the Model B version:
MMFS_1_07.zip
I've not tested it, because I'm a bit in the middle of something else, but give it a go.

Dave
Reading the old thread I understand there is also a model B SWR version?

I wonder if the model B version is compatible with Econet and how it behaves with solidisk sideways ram..
Paul

Image

User avatar
Lardo Boffin
Posts: 1831
Joined: Thu Aug 06, 2015 6:47 am
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by Lardo Boffin » Mon Jan 11, 2016 4:41 pm

hoglet wrote:
Lardo Boffin wrote: At the risk if sounding like a 'numpty' where is the correct download file or could some kind person attach it to a message in this topic please? It is for a model B.
The version attached four posts up is actually the Master 128 version and won't work on the model B (hence the MA prefix to MMFS, sorry slightly obscure....)

I've just built you the Model B version:
MMFS_1_07.zip
I've not tested it, because I'm a bit in the middle of something else, but give it a go.

Dave

Thanks Dave.

That loads into sideways RAM and shows when I do *Help. I can do *MMFS but it just says 'Card?' afterwards.
I am using a turbo mmc card reader so am probably being hopelessly naive to think this ROM would work with that hardware?

Do I need to get the guy who makes them to update his software?

Thanks, Lardo
Atom, issue 5
Elk
BBC model B 32k issue 4, 16k sideways RAM, Watford 12 ROM board, Acorn 6502 coproc
BBC model B 32k issue 7, turboMMC, Opus Challenger 3 512k, Pi 3 coproc
USA Model B
BBC Master, Datacentre + HDD, pi co-proc, econet, NULA

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Mon Jan 11, 2016 4:47 pm

DutchAcorn wrote:
hoglet wrote:
Lardo Boffin wrote: At the risk if sounding like a 'numpty' where is the correct download file or could some kind person attach it to a message in this topic please? It is for a model B.
The version attached four posts up is actually the Master 128 version and won't work on the model B (hence the MA prefix to MMFS, sorry slightly obscure....)

I've just built you the Model B version:
SWMMFS_1_07.zip
(10.35 KiB) Downloaded 38 times
I've not tested it, because I'm a bit in the middle of something else, but give it a go.

Dave
Reading the old thread I understand there is also a model B SWR version?

I wonder if the model B version is compatible with Econet and how it behaves with solidisk sideways ram..
Feel free to give it a try.....
SWMMFS_1_07.zip
(10.35 KiB) Downloaded 38 times
This uses sideways RAM (in the same slot as MMFS is loaded to) from B600-BFFF as file system workspace. So you need to avoid write-protecting this slot.

And again, I have not tested this myself.

Dave

User avatar
sweh
Posts: 2131
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by sweh » Mon Jan 11, 2016 4:47 pm

Lardo Boffin wrote:Do I need to get the guy who makes them to update his software?
Steve Picton is aware of the bug, but he doesn't have a fix available yet.
Rgds
Stephen

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Mon Jan 11, 2016 4:49 pm

Lardo Boffin wrote: Thanks Dave.

That loads into sideways RAM and shows when I do *Help. I can do *MMFS but it just says 'Card?' afterwards.
I am using a turbo mmc card reader so am probably being hopelessly naive to think this ROM would work with that hardware?

Do I need to get the guy who makes them to update his software?
Quite possibly - I don't know if Turbo MMC uses the same user port connections as MMBEEB/MMFS needs.

Edit: Is seems TurboMMC is wired differently.

Is it Steve Picton? He's usually quite helpful.

Dave

User avatar
DutchAcorn
Posts: 2162
Joined: Fri Mar 21, 2014 9:56 am
Location: Maarn, Netherlands
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by DutchAcorn » Mon Jan 11, 2016 6:52 pm

hoglet wrote:
Lardo Boffin wrote: Thanks Dave.

That loads into sideways RAM and shows when I do *Help. I can do *MMFS but it just says 'Card?' afterwards.
I am using a turbo mmc card reader so am probably being hopelessly naive to think this ROM would work with that hardware?

Do I need to get the guy who makes them to update his software?
Quite possibly - I don't know if Turbo MMC uses the same user port connections as MMBEEB/MMFS needs.

Edit: Is seems TurboMMC is wired differently.

Is it Steve Picton? He's usually quite helpful.

Dave
Duikkie worked it out and implemented it in his SmartSPI FS: viewtopic.php?f=2&t=9208&hilit=Smart&start=90#p112183
Paul

Image

User avatar
jgharston
Posts: 3839
Joined: Thu Sep 24, 2009 11:22 am
Location: Whitby/Sheffield
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by jgharston » Mon Jan 11, 2016 9:33 pm

There's another bug in there. It contains the TUBE 2.30 host, which calls OSBYTE &E9 in its HELP routine at SERVICE09_TUBEHelp. That should be OSBYTE &EA to read the Tube Presence flag, not the VIA interupt mask, so that the HELP message is displayed if the Tube is present.

Code: Select all

	CMP #&0D
	BNE Label_AED3
	LDA #&E9 ; should be &EA - Tube Presence Flag
	JSR osbyte_X0YFF
and later on:

Code: Select all

	LDX #&06
	LDA #&14
	JSR OSBYTE	; Enable ESCAPE pressed event
No, OSBYTE &14 is explode character set. OSBYTE 14 is enable events. See link.

Code: Select all

$ bbcbasic
PDP11 BBC BASIC IV Version 0.25
(C) Copyright J.G.Harston 1989,2005-2015
>_

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Wed Jan 13, 2016 10:54 am

to understand the problem. the problem is only if you use the OSWORD call with a=&7f, anything else is good ?
you can load/save to tube(co-pro) if you are using normal *load or load ???

the osword7f in mmc and other roms are replaced by a osword7f in file 8-cow. and this is called only in the dfs rom at &94ff.

it use bptr% (what is &B0) and so on.

so tell me more :)

your file loads wrong in memory from beeb. and the other param. are allways corect ? if sec load are 3 then you have 3 sectors in memory(in the wrong place?)
if you use other then drive 0 is it correct ?

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Wed Jan 13, 2016 11:03 am

more questions

if you load your program at &5000

is the 2 sectors then in 5000 and 5100 ?? or at 2000.. 2100 ?

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Wed Jan 13, 2016 4:23 pm

oke i know where the error is and why you get a file at &130A

in the file 8-cow at osword7f the resultbyte is at fvars%=&be and the stript commandcode from &53 and #&3f=&13 stored in fdcop%=fvars%+1.

and &be and so on are the parameters from your file
&be=load,exec,length,sector.

i have to look further in the osword7f call to see if i can replace result% to &bc and fdcop% to &bd leaving &be ans on free for fvars% of the file.

maybe there will be an update :shock: , but i have to do this while bill is not looking :) , because mmc is so 2015.
USB is the new standaard :lol:
sweh wrote:Based on some testing I did with the matchbox CoPro and TurboMMC I think I may have found an issue with OSWORD 7F routines. I did the same test with Smart SPI and got identical results. So it's possible this error has been there since the early MM code days...

Here is my test code:

Code: Select all

   10DIM BLOCK% 100
   20D%=&2000
   30?BLOCK%=0
   40BLOCK%!1=D%
   50BLOCK%?5=3
   60BLOCK%?6=&53 : REM READ SECTOR
   70BLOCK%?7=0   : REM TRACK
   80BLOCK%?8=0   : REM SECTOR
   90BLOCK%?9=&22 : REM TWO SECTORS
  100X%=BLOCK%
  110Y%=X%/256
  120A%=127
  130CALL &FFF1
Now if I run this on a non-copro Beeb (*FX151 230 6) it works correctly. The first 2 sectors are loaded into &2000

If I turn the CoPro on (*FX151 230 1) and run it... the data loads at &130A instead. In testing with TurboMMC, and using BeebEm for comparison:
1) BeebEm no CoPro: works
2) BeebEm with 65C02 CoPro: works
3) BBC B with no CoPro and TurboMMC: works
4) BBC B with Matchbox CoPro and TurboMMC: loads at &130A
5) Master with no CoPro and TurboMMC: works
6) Master with John Kortink's internal 65C102 and TurboMMC: loads at &130A

(in fact there were two BBC B's; one issue 4, one issue 7, both the same results).

It doesn't matter what I set D% to, it always loads at 130A which makes me wonder if the OSWORD 7F routine is corrupting the address value somewhere.

I was told SmartSPI also worked with TurboMMC (it seems to!), so I tested that (tests 3 and 4)... exactly the same results. The sectors are loaded at &130A. This makes me think there might be a problem with the code going all the way back to Martin's original routines.

This normally has no impact (it seems to require OSWORD 7F and a copro to exercise it) so I'm not too surprised it hasn't been seen before. The Z80 copro uses it to try and load CPM, which is where I saw it.

Can anyone else verify this? Is my code just bad and wrong (it works on BeebEm...) or is there a bug?

Duikkie? Dunno if you're in a position to test/verify...

User avatar
sweh
Posts: 2131
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by sweh » Thu Jan 14, 2016 5:10 am

duikkie wrote:but i have to do this while bill is not looking :)
Bill believed in legacy support for successful products; just look at how long XP was supported for. It was only after Bill moved on that XP was retired.

Bill didn't believe in supporting bad products (Microsoft Network; WIndows ME Harder; etc) but successful products (XP, SmartSPI) were supported for a long time.
Rgds
Stephen

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Thu Jan 14, 2016 5:16 am

:shock: :oops: :roll: , i changed mmc/turbo rom last year in smart spi , maybe if i live long , somewhere i can support smart spi :?:

sweh wrote:
duikkie wrote:but i have to do this while bill is not looking :)
Bill believed in legacy support for successful products; just look at how long XP was supported for. It was only after Bill moved on that XP was retired.

Bill didn't believe in supporting bad products (Microsoft Network; WIndows ME Harder; etc) but successful products (XP, SmartSPI) were supported for a long time.

User avatar
sweh
Posts: 2131
Joined: Sat Mar 10, 2012 12:05 pm
Location: New York, New York
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by sweh » Thu Jan 14, 2016 5:36 am

And Bill also believed in code re-use. Windows 10 has a lot of code of XP in it. Probable that the new super-duper USB code has the same bug, so fix it there and "backport" :lol: :lol: :lol:
Rgds
Stephen

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Thu Jan 14, 2016 6:25 pm

i don't no way if tube is there it loads from &be and &bf. the osword7f in 8-cow point to &b1 and b2 ??

i can change it that both load from &be and &bf , upload &b1 and &b2 , from BLOCK to &BE and &BF

but that is not the solution , something , somewhere with coprocessor it loads from &be.... (fvars%) and without from bprt% ??

still looking where the bug is

User avatar
tricky
Posts: 4017
Joined: Tue Jun 21, 2011 8:25 am
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by tricky » Thu Jan 14, 2016 9:42 pm

Are you sure it isn't the same bug that was in the other MMC based versions? and that the fix for them won't work?

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Fri Jan 15, 2016 6:52 am

i am not sure what the bug really is, because i don't have a coprocessor. when i look at the osword7f in 8-cow and debug it , it works oke.somehow if coprocessor is present it use &be and &bf to read the load adress and not &b1 and &b2 (bprt%+1.bprt%^+2) , the osword7f calculate total param. adc #7 in result that is for read/write &0a in &be, and parm &53 and #&3f=&13 in fdcop% what is in &bf.

i do not understand why with copro the osword7f get the load adress from &be..&bf what is &130A ? it is bprt+1 in the routine(=&b1).

i can fix it so that &b1 and &b2 is copyed to &be,&bf, and i think that will work

BUT why reading and writting from &be .. &bf. i am looking where the coprocessor is doing that and where ???

somewhere the memory to load/write is moved by coprocessor from &b0 to &be ???.

tricky wrote:Are you sure it isn't the same bug that was in the other MMC based versions? and that the fix for them won't work?

User avatar
hoglet
Posts: 8930
Joined: Sat Oct 13, 2012 6:21 pm
Location: Bristol
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by hoglet » Fri Jan 15, 2016 8:12 am

Hi Duikkie,
duikkie wrote:somewhere the memory to load/write is moved by coprocessor from &b0 to &be ???.
In MMFS there appears to be some additional code that is missing from SmartSPI:
https://github.com/hoglet67/BeebFpga/bl ... 7F.asm#L32

Code: Select all

	\ Copy buffer address to &BC-&BD;&1074-&1075
	STY byteslastsec%
	INY
	LDX #2
	JSR CopyVarsB0BA
Here's the CopyVarsB0BA code:
https://github.com/hoglet67/BeebFpga/bl ... 0.asm#L304

Code: Select all


.CopyVarsB0BA
{
	JSR CopyWordB0BA
	DEX 
	DEX 				;restore X to entry value
	JSR cpybyte1			;copy word (b0)+y to 1072+x
.cpybyte1
	LDA (&B0),Y
	STA MA+&1072,X
	INX 
	INY 
	RTS 
}
.CopyWordB0BA
{
	JSR cpybyte2			;Note: to BC,X in 0.90
.cpybyte2
	LDA (&B0),Y
	STA &BA,X
	INX 
	INY 
	RTS
}
Maybe something like this is needed in SmartSPI?

But the two code bases are actually quite different (though they do share some common code fragments).

Dave

duikkie
Posts: 2985
Joined: Fri Feb 07, 2014 3:28 pm
Contact:

Re: TurboMMC / SmartSPI, CoPro, OSWord 7F loads to wrong address

Post by duikkie » Fri Jan 15, 2016 8:54 am

no problem to do that in my rom, but i want to understand why with copro , it loads from &be instead of &b1 what the rountine is telling ???

#-o
hoglet wrote:Hi Duikkie,
duikkie wrote:somewhere the memory to load/write is moved by coprocessor from &b0 to &be ???.
In MMFS there appears to be some additional code that is missing from SmartSPI:
https://github.com/hoglet67/BeebFpga/bl ... 7F.asm#L32

Code: Select all

	\ Copy buffer address to &BC-&BD;&1074-&1075
	STY byteslastsec%
	INY
	LDX #2
	JSR CopyVarsB0BA
Here's the CopyVarsB0BA code:
https://github.com/hoglet67/BeebFpga/bl ... 0.asm#L304

Code: Select all


.CopyVarsB0BA
{
	JSR CopyWordB0BA
	DEX 
	DEX 				;restore X to entry value
	JSR cpybyte1			;copy word (b0)+y to 1072+x
.cpybyte1
	LDA (&B0),Y
	STA MA+&1072,X
	INX 
	INY 
	RTS 
}
.CopyWordB0BA
{
	JSR cpybyte2			;Note: to BC,X in 0.90
.cpybyte2
	LDA (&B0),Y
	STA &BA,X
	INX 
	INY 
	RTS
}
Maybe something like this is needed in SmartSPI?

But the two code bases are actually quite different (though they do share some common code fragments).

Dave

Post Reply