DragonMMC Announcement.

For the discussion of all hardware related topics.
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DragonMMC Announcement.

Post by pser1 »

Hi Phill,
while I have been searching inside the source code of EXPV1.DGN, I have found three sentences that "could" be wrong, they are:
Lines 6055 and 6075 where you can find "DS=FLASE"
And line 6330 where I found "CC=FLASE"
Shouldn't they be FALSE instead?
cheers
pere
prime
Posts: 266
Joined: Fri Apr 10, 2009 1:40 am

Re: DragonMMC Announcement.

Post by prime »

pser1 wrote:while I have been searching inside the source code of EXPV1.DGN, I have found three sentences that "could" be wrong, they are:
Lines 6055 and 6075 where you can find "DS=FLASE"
And line 6330 where I found "CC=FLASE"
Shouldn't they be FALSE instead?
I suspect they should be FALSE, I've punted the report to Richard Harding who wrote the explorer. One thing I did confirm with him though is that Explorer *ASSUMES* that .BIN file is a ROM as there are a log of CoCo ROM images that have the extension .BIN. A future firmware upgrade will add a function that can be used to check for the header so hopefully resolve this.

The solution for now is to rename them as .DGN which the explorer should load correctly, assuming the stack isn't getting borked :)

Thanks for the bug reports and feedback by the way, despite the extensive testing that my testers did, you can never catch them all, reporting the bugs constructively is how they hopefully get fixed......

Cheers.

Phill.
dragondata
Posts: 11
Joined: Tue Jun 22, 2010 8:51 pm
Location: Wilts
Contact:

Re: DragonMMC Announcement.

Post by dragondata »

The lines at 6055 and 6075 do contain a typo but it will run fine as FALSE is 0 and FLASE will also be 0 as well as it's not used. Thx and I'll sort it on the next release. :D

As Phill mentioned .BIN is assumed to be a CoCo ROM (cart) image so at the moment these's no direct way to load a M/C .BIN file from the explorer and renaming it to .DGN sadly won't trick the explorer. As a work around you'll need to eXit out of explorer (not BREAK out) and use MLOAD "DOWNLAND.BIN" and EXEC if needed. Hopefully we can resolve this in the next release. :)


Regards
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DragonMMC Announcement.

Post by pser1 »

dragondata wrote:The lines at 6055 and 6075 do contain a typo but it will run fine as FALSE is 0 and FLASE will also be 0 as well as it's not used. Thx and I'll sort it on the next release. :D
Hi, I saw it, but I thought it was so easy to 'solve' this 'aesthetic' difference
As Phill mentioned .BIN is assumed to be a CoCo ROM (cart) image so at the moment these's no direct way to load a M/C .BIN file from the explorer and renaming it to .DGN sadly won't trick the explorer. As a work around you'll need to eXit out of explorer (not BREAK out) and use MLOAD "DOWNLAND.BIN" and EXEC if needed. Hopefully we can resolve this in the next release. :)Regards
Yes, this is exactly the procedure I said that works well right now!
I have changed the extension to .DGN and fails from the Explorer, but works well with MLOADA"DOWNLAND.DGN" from outside it.
To me this could be caused for the fact that the stack is sent far down ($6e6a) compared to the default value $7f36 due to the CLEAR 4500
As most programs do not set the stack pointer, as is the case for Downland, it uses the stack that is pointing inside the program, so corrupting itself
Maybe a double poke setting stack at $7f36 could work ... but interrupts are enabled, so complicated from within Basic.
cheers
pere
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DragonMMC Announcement.

Post by pser1 »

Hi Phill,
I have worked a bit on the 'BIG' programs that could cause problems when loaded from inside
the Explorer due to the stack being too low. I include here the 'small' mods needed in the basic
program so that it works flawlessly

Code: Select all

2665 PRINT @511,"";
2666 LM$="1A50308C0C9FA610CE7F361CAF7E839839"
2667 LM$=LM$+"4D4C4F41444120444924284346290000"
2668 J=0:FORI=1TO65STEP2:A$=MID$(LM$,I,2):POKE&H2B0+J,VAL("&H"+A$):J=J+1:NEXT
2670 EXEC&H2B0:'MLOADA DI$(CF)
2690 'PRINT @511,"";
And to help understand what it does, this is the disassembled routine that is called everytime we need MLOADA

Code: Select all

			org	$02b0							; tape buffer
			orcc	#$50							; disable interrupts
			leax	Comnd,pcr					; get command address
			stx	<$a6							; put in system pointer
			lds	#$7f36						; set stack (as after CLEAR200,&H7fff) 
			andcc	#$af							; enable interrupts
			jmp	$8398							; call Basic Commands Interpreter
			rts									; return (not needed), but ...
Comnd		fcn	/MLOADA DI$(CF)/,0,0		; command to be executed
pgmEnd	equ	*
This is a possible solution. If it works for you, then it could be used for MTAPELOAD as well with very few changes.
With these changes, DOWNLAND.DGN works without problems!
cheers
pere
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DragonMMC Announcement.

Post by pser1 »

Hi Phill,
back again to complement previous message.
Tha patch I commented will only work for Dragon computers, but adding a single line
we can make it work for CoCo-Draco machines too.

Code: Select all

2669 IF MGETCFG(255)=2 THEN POKE&H2BE,&HAC:POKE&H2BF,&H9A
This line changes the Interpreter address to be called if a CoCo is detected. The new one is $AC9A instead of $8398
cheers
pere
prime
Posts: 266
Joined: Fri Apr 10, 2009 1:40 am

Re: DragonMMC Announcement.

Post by prime »

Hi all,

In the next version of ther firmware (which is being worked on at the mo), there will be a version of MLOAD that will clear the memory back to power on setup before loading the file, like MTAPELOADA does currently (and it indeed shares the same code). Which should hopefully fix this problem.

I'm currently doing a partial re-write of the disk image handling code to allow it to be able to create images so that you can MDISKI a new image file and then DSKINIT it to create the image.

Cheers.

Phill.
sardine
Posts: 16
Joined: Wed Sep 27, 2017 7:30 pm

Re: DragonMMC Announcement.

Post by sardine »

having owned a dragon 32 since I was 12 and now a dragon 64 i'm so looking forward to this.

I have a cocosdc but find it very difficult to use as it was designed primarily for the coco

the most exciting feature for me is loading tape files from SD and the snapshot/save state feature.

I'm just waiting now for the email to land asking for payment :D
pser1
Posts: 1655
Joined: Sun Mar 25, 2012 7:32 pm
Location: Barcelona (SPAIN)

Re: DragonMMC Announcement.

Post by pser1 »

Hi Phill,
'sardine' has tried to use 720k VDK on the MMC and the result has been ... IV ERROR
I have tried disks 720k DW4 compatible (length multiple of 256) and without padding the header (std)
Both versions return the IV ERROR message
In fact I have tested right now with disks 360k, for instance to play my port of The Hobbit ... same result: IV ERROR
Is there any way to use discs bigger than the 180K ones?
Thanks in advance
pere

Ps I attach here a zip containing an VDK 360k and another 720k
MoreThan184K.ZIP
(380.78 KiB) Downloaded 513 times
prime
Posts: 266
Joined: Fri Apr 10, 2009 1:40 am

Re: DragonMMC Announcement.

Post by prime »

Hi all,

I have a firmware update almost ready for release, which will hopefully fix the issue with disk images, will hopefully be in the next week or so.

Cheers,

Phill.
Post Reply