UK Vintage Radio Repair and Restoration Powered By Google Custom Search Vintage Radio and TV Service Data

Go Back   UK Vintage Radio Repair and Restoration Discussion Forum > Specific Vintage Equipment > Vintage Computers

Notices

Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment.

Reply
 
Thread Tools
Old 16th Dec 2021, 11:45 am   #21
coolsnaz2
Triode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 25
Default Re: Yet another MK14 tape interface (ESP32).

Ok this time I used sbasm to produce the code.

Code:
	.CR scmp
	.TF BootLoader3.hex, INT
	;
	; coolsnaz2 (IFM 2021)


COUNT	.EQ 0x75 	;Change to 0xD5 after assembled
LEN	.EQ 0x76	;Change to 0xD6 after assembled
        .OR 0x0880
		
		
BEGIN	JS 2,GBYTE
		LDE
		XPAH 1
		JS 2,GBYTE
		LDE
		XPAL 1
		JS 2,GBYTE
		LDE
		ST LEN(3)
		
START	JS 2,GBYTE
		LDE
		ST @+1(1)
		DLD LEN(3)
		JNZ START
		JS 2,GBYTE
		LDE
		XPAH 3
		JS 2,GBYTE
		LDE
		XPAL 3		
		RET 3


GBYTE	LDI 8		;Loop Bits In Byte
		ST COUNT(3)
LOOP	CSA
		ANI 0x20
		JZ LOOP
		SIO
LOOP2	CSA		
		ANI 0x20
		JZ LOOP2
		DLD COUNT(3)
		JNZ LOOP
		RET 2
This is the new Boot Loader I am using, takes 21 seconds to load using using the standard MK 14 tape interface, I currently load at 0880.

All subsequent loads will use this Loader, Moon Lander takes under 1 second to load.

The M5StickC program has been updated to send load address, file length and execution address. This reduces need to enter these into the MK14. Programs now load to correct address and execute automatically.

I have a slight problem with the assembler, the values for COUNT and LEN need to be changed after the code has been assembled. I think this relates to the assembler not knowing that P3 is set to 0x0023.

Not sure if it's worth updating the load process to accept the .hex files produced by the sbasm.
coolsnaz2 is offline   Reply With Quote
Old 17th Dec 2021, 11:45 am   #22
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 8,539
Default Re: Yet another MK14 tape interface (ESP32).

I believe SBASM3 can produce .BIN files as easily as it can .INT, just a question of changing the parameters in the .TF line I think.

The main advantage from using Intel Hex rather than a binary-with-header format is that Intel Hex allows you to send your code to physically separate areas of the memory all in the same load operation.

The three blocks of onboard memory provided for on the MK14, namely

0F00-0FFF - standard RAM
0B00-0BFF - optional extra RAM
0880-08FF - RAM in RAM I/O device

...are not continuous, so it wouldn't be possible to load a 512 byte program into 0F00-0FFF and 0B00-0BFF in a single load operation due to the fact that the two RAM areas are not continuous.

With Intel Hex, the code is continually directed to the correct destination addresses by virtue of the fact that each line of code commences with the address of the first data byte in the line.

I don't currently have time to get my head around your problem with the .EQ lines for COUNT and LEN not producing the right values in the code as I am at work, but it's true that the code as written has no way to 'know' what value P3 contains upon entry. If you do know, then you may have to define those offsets with the correct values yourself.
SiriusHardware is online now   Reply With Quote
Old 17th Dec 2021, 2:18 pm   #23
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 8,539
Default Re: Yet another MK14 tape interface (ESP32).

Can I just ask you to clarify:

Code:
COUNT	.EQ 0x75 	;Change to 0xD5 after assembled
LEN	.EQ 0x76	;Change to 0xD6 after assembled
Do you mean that after assembly these offset values have mysteriously changed from 0x75 and 0x76 to 0xD5 and 0xD6,

or...

Do you mean that they contain the values 0x75 and 0x76 and you have to manually change those offsets to 0xD5 and 0xD6 for correct operation of the program?
SiriusHardware is online now   Reply With Quote
Old 17th Dec 2021, 7:48 pm   #24
coolsnaz2
Triode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 25
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
Originally Posted by SiriusHardware View Post
Can I just ask you to clarify:

Do you mean that after assembly these offset values have mysteriously changed from 0x75 and 0x76 to 0xD5 and 0xD6,

or...

Do you mean that they contain the values 0x75 and 0x76 and you have to manually change those offsets to 0xD5 and 0xD6 for correct operation of the program?
Your second option is true, the assembler comes back with

*** Error: Out of range
20 ST LEN(3)

Any value over 0x80 produces the error, so I allow sbasm to assemble the program with 0x75 and 0x76 and then manually change offsets.

Program currently limited to 256 bytes per load, but since each load only takes 1 second to load, not sure if this is a problem.

If you are developing code for the MK14, the M5StickC program could be developed to accept a file from a PC via WiFi. Currently I have to compile the arduino sketch ever time I make changes to the file transfer process or add additional programs.
coolsnaz2 is offline   Reply With Quote
Old 17th Dec 2021, 8:45 pm   #25
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,154
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
Originally Posted by coolsnaz2 View Post
I have a slight problem with the assembler, the values for COUNT and LEN need to be changed after the code has been assembled. I think this relates to the assembler not knowing that P3 is set to 0x0023.
.
When writing SC/MP programs, if one of the pointer registers is preset to some value, I tend to assign a symbol to that value and then put the appropriate calculation in the code. This seems to fix most of the offset problems I get.

e.g. in this code P1 is set to the same as the 'Ret' label in the program, and the locations 'Row' and 'Count' (at 0xF03 and 0xF04 respectively) are always accessed relative to P1.
Code:
; These values are the offset relative to P1 which points to 
; 0xF20, or the Ret label. All variables are stored before this 
; memory location at -ve offsets.
Row     .EQ 0xF03-Ret   ;Ram Offsets
Count   .EQ 0xF04-Ret
;
Slothie is offline   Reply With Quote
Old 19th Dec 2021, 1:56 pm   #26
Phil__G
Pentode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 236
Default Re: Yet another MK14 tape interface (ESP32).

I find relative addressing problems can be largely down to the syntax used, mine were all fixed with the updated crscmp.py file, though the original NS Kitbug source needed many syntax & method changes before sbasm produced code identical to the original. Of the many ways to express something, it often seems sbasm often likes only one particular way, and its a case of finding that syntax!
I'm puzzled by "RET 2" and RET 3", are these pre-defines in sbasm that I've missed? (I confess I havent studied the sbasm documentation, I just dived in...)
Cheers
Phil
Phil__G is offline   Reply With Quote
Old 19th Dec 2021, 2:42 pm   #27
coolsnaz2
Triode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 25
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
Originally Posted by Phil__G View Post
I'm puzzled by "RET 2" and RET 3", are these pre-defines in sbasm that I've missed? (I confess I havent studied the sbasm documentation, I just dived in...)
Cheers
Phil
sbasm has added two instructions.

JS Jump to Subroutine

JS pntr,destination

which translates to
Code:
        LDI     /destination-1
        XPAH    pntr
        LDI     #destination-1
        XPAL    pntr
        XPPC    pntr
and

RET Return from Subroutine

RET pntr
coolsnaz2 is offline   Reply With Quote
Old 19th Dec 2021, 2:58 pm   #28
Phil__G
Pentode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 236
Default Re: Yet another MK14 tape interface (ESP32).

Well every day is a school day, thank you! I really should read the sbasm documentation.
My excuse is that I tend to avoid macros, long-hand works for me, I tend to think from the targets point of view which of course sees no difference
My next puzzle is how Slothie's example will try to interpret a predefined macro name as a value? do you 'undefine' the RET macro so ret can be used as a label?
Code:
; These values are the offset relative to P1 which points to 
; 0xF20, or the Ret label. All variables are stored before this 
; memory location at -ve offsets.
Row     .EQ 0xF03-Ret   ;Ram Offsets
Count   .EQ 0xF04-Ret
;
See why I avoid macros?

Last edited by Phil__G; 19th Dec 2021 at 3:09 pm.
Phil__G is offline   Reply With Quote
Old 19th Dec 2021, 3:45 pm   #29
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 8,539
Default Re: Yet another MK14 tape interface (ESP32).

The cause for confusion seems to be that Slothie referred to a LABEL Ret: whereas RET in the example program is one of SBASM3's psuedo-instructions.

Although handy, the JS pseudo-instruction and its RET counterpart only really serve to mask the alarming number of bytes that a subroutine call costs in SC/MP - I sometimes think it's better to be aware of how many bytes you are using even if it means writing code out in full so you can count every byte.

Like Phil, I'm not keen on Macros or even #include libraries myself, I prefer everything in one big single source file so I can whizz up and down and look at any part of it at will.
SiriusHardware is online now   Reply With Quote
Old 20th Dec 2021, 9:14 am   #30
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,154
Default Re: Yet another MK14 tape interface (ESP32).

I wasn't aware of JS and RET

Sorry for the confusion!
Slothie is offline   Reply With Quote
Old 20th Dec 2021, 9:51 am   #31
Phil__G
Pentode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 236
Default Re: Yet another MK14 tape interface (ESP32).

Quote:
Originally Posted by Slothie View Post
I wasn't aware of JS and RET
Thats good news Slothie, I feel better now!
Phil__G is offline   Reply With Quote
Old 20th Dec 2021, 1:33 pm   #32
Slothie
Octode
 
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,154
Default Re: Yet another MK14 tape interface (ESP32).

I don't mind macros in assembler, it can make programming complex programs a lot clearer, but they do mask register usage, so can lead to problems. For instance the "JS" built in psuedo-op changes the accumulator which is not obvious, and "JS" looks like an ordinary opcode which has no reason to affect the accumulator. At least in SBASM actual macro calls stand out because they are prefixed with a '>' character, and therefore warn you to look at the expansion in the listing.
Slothie is offline   Reply With Quote
Old 27th Dec 2021, 8:53 pm   #33
coolsnaz2
Triode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 25
Default Re: Yet another MK14 tape interface (ESP32).

Updated version that does not use JS or RET, and solves issues I had with offsets. Program now needs to run in RAM but should be relocatable.

Code:
	.CR scmp
	.TF BL7.hex, INT
	;
	; Converted to SBASM by IFM 2021

        .OR 0x0880
COUNT	.BS 1
LEN  	.BS 1
TASK 	.BS 1


START	LDI 0x01

STTASK	ST TASK

GBYTE	LDI 8		;Loop Bits In Byte
	        ST COUNT
LOOP        CSA
	        ANI 0x20
	        JZ LOOP
	        SIO
LOOP2      CSA		
	        ANI 0x20
	        JNZ LOOP2
	        DLD COUNT
	        JNZ LOOP
		
	        LD TASK
TASK1	ANI 0x01	;Task1 is High Byte of load address
	        JZ TASK2
	        LDE
	        XPAH 1
	        LDI 0x02
	        JMP STTASK
		
TASK2	LD TASK		;Task2 is Low Byte of load address
	        ANI 0x02
	        JZ TASK4
	        LDE
	        XPAL 1
	        LDI 0x04
	        JMP STTASK	
		
TASK4	LD TASK		;Task4 is Length of load
	        ANI 0x04
	        JZ TASK8
	        LDE
	        ST LEN
	        LDI 0x08
	        JMP STTASK		

TASK8	LD TASK		;Task8 is load of data
	        ANI 0x08
	        JZ TASK10
	        LDE
	        ST @+1(1)
	        DLD LEN
	        JNZ GBYTE
	        LDI 0x10
	        JMP STTASK		
		
TASK10	LD TASK		;Task10 is High byte of execution address
	        ANI 0x10
	        JZ TASK20
	        LDE
	        XPAH 3
	        LDI 0x20
	        JMP STTASK
		
TASK20	LDE		;Task20 is High byte of execution address
	        XPAL 3
	        XPPC 3
Still able to load Moon Lander in under a second. Also found mistake in the code I posted on the 16th Dec 21, JZ LOOP2 should be JNZ LOOP2.
coolsnaz2 is offline   Reply With Quote
Old 28th Dec 2021, 5:24 pm   #34
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 8,539
Default Re: Yet another MK14 tape interface (ESP32).

Thanks for the update and corrections - sounding good.
SiriusHardware is online now   Reply With Quote
Old 28th Dec 2021, 7:00 pm   #35
Phil__G
Pentode
 
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 236
Default Re: Yet another MK14 tape interface (ESP32).

Trivial, but a copy & paste typo
Code:
TASK20	LDE		;Task20 is High byte of execution address
Phil__G is offline   Reply With Quote
Old 28th Dec 2021, 8:22 pm   #36
coolsnaz2
Triode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 25
Default Re: Yet another MK14 tape interface (ESP32).

Yes sorry, cut and paste typo. ; Task20 is Low byte of execution address
coolsnaz2 is offline   Reply With Quote
Old 10th Apr 2022, 4:47 pm   #37
coolsnaz2
Triode
 
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 25
Default Re: Yet another MK14 tape interface (ESP32).

Advice/Help needed.
Since creating my sync interface for the MK14, I have decided to try and create a replica of the MK14, so that my original can be put back in its box for another 10 years.
I have ordered Replica PCB and SC/MP from ebay. I would like to use a single chip for the ROM and another chip for the RAM, both 1k.
My questions, has this been done before?, if so what ROM and RAM should I use.
My criteria is that I/O and speed should be the same as original MK14, but physically appearance does not have to be the same.
coolsnaz2 is offline   Reply With Quote
Old 10th Apr 2022, 6:21 pm   #38
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 8,539
Default Re: Yet another MK14 tape interface (ESP32).

Which PCB did you order? If (by chance) it was an 'issue VI' then that particular board has all the needed bus signals taken back to the rear edge connector - you can therefore just leave the onboard RAM and ROM sockets unpopulated and make a plug-in RAM/ROM pack (in best Sinclair tradition) which contains a generously sized conventional RAM like a 62256, a conventional EPROM like a 2716 (or larger, doesn't matter, you are only going to enable the first 512 bytes) and a bit of address decoding logic.

The various RAM memory areas on the MK14 are rather spread out (not continuous) so you might prefer to make your life easier by using a larger memory IC which spans the whole required range and just enabling the relevant parts of it whenever an address in a valid RAM range is accessed.

For example, valid RAM ranges on an issue V or issue VI MK14 include:-

0200-07FF (There is no position on the PCB for this RAM, you have to add it, and its address decoding, yourself). On original issue II, III, IV PCBs and the JMP replica PCBs this address range is not free to use as it is occupied by 'images' of the PROMs.

0880-08FF (the RAM in the 8154 I/O RAM, if fitted)

0B00-0BFF (the 'optional' extra 256 bytes of RAM, if fitted)

0F00-0FFF (the original 256 bytes of RAM)

These addresses all exist within a 4K or greater RAM, so I would suggest using at least a 4K RAM and then all you have to do is enable the parts of it corresponding to the address ranges above. (if you plan to fit an 8154, then don't include the 0880-08FF range).

If you've ordered a 'Martin L' (one of the Czech replicas) then he can also provide the solution to your problem, a plug in RAM / ROM PCB.

https://www.8bity.cz/2018/science-of...ram-expansion/

Although designed for Martin's very authentic looking replica PCBs it may work in any other original issue V or issue V clone or indeed in the issue VI, since it plugs into the CPU socket and then the CPU plugs into the RAM / ROM daughterboard - maybe Slothie (designer of the issue VI) can confirm whether this should work.

Can I ask why you want to use wide bodied ICs, is it just because you assume you can't get the proper PROMs and RAM easily, or is it because you want to try your own custom code modifications to the PROM code?
SiriusHardware is online now   Reply With Quote
Old 10th Apr 2022, 7:08 pm   #39
Timbucus
Octode
 
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,169
Default Re: Yet another MK14 tape interface (ESP32).

I actually bought a ready made expansion board from an ebay listing as well for one of my MK14's - I have not tested it on the JM Precision one but, see no reason it would not work.

Click image for larger version

Name:	IMG_4714.jpg
Views:	14
Size:	49.6 KB
ID:	255111

If you have original PROM's though I on an Issue VI or V like the Martin one that Slothie's PCB for the Ortonview Video expansion allows the most fun and provides additional memory.
Timbucus is online now   Reply With Quote
Old 10th Apr 2022, 7:20 pm   #40
SiriusHardware
Dekatron
 
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 8,539
Default Re: Yet another MK14 tape interface (ESP32).

I don't think the JMP PCB has the memory hole free at 0200 to 07FF as it is an 'issue 0' replica - you can tell us that, just look at addresses 0000, 0200, 0400, 0600 and say whether the last three contain the same value as the first address.

Unless of course your expansion PCB only seeks to replace the original RAM at 0B00-0BFF and 0F00-0FFF?

I have a feeling csnz2 wants an EPROM that he can freely reprgramme himself, so that he can put his fast loading routines into (E)PROM.
SiriusHardware is online now   Reply With Quote
Reply

Thread Tools



All times are GMT. The time now is 10:18 pm.


All information and advice on this forum is subject to the WARNING AND DISCLAIMER located at https://www.vintage-radio.net/rules.html.
Failure to heed this warning may result in death or serious injury to yourself and/or others.


Powered by vBulletin®
Copyright ©2000 - 2022, vBulletin Solutions, Inc.
Copyright ©2002 - 2021, Paul Stenning.