|
Vintage Computers Any vintage computer systems, calculators, video games etc., but with an emphasis on 1980s and earlier equipment. |
|
Thread Tools |
16th Dec 2021, 12:45 pm | #21 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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 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. |
17th Dec 2021, 12:45 pm | #22 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
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. |
17th Dec 2021, 3:18 pm | #23 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
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 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? |
17th Dec 2021, 8:48 pm | #24 | |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
Re: Yet another MK14 tape interface (ESP32).
Quote:
*** 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. |
|
17th Dec 2021, 9:45 pm | #25 | |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Yet another MK14 tape interface (ESP32).
Quote:
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 ; |
|
19th Dec 2021, 2:56 pm | #26 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,115
|
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 |
19th Dec 2021, 3:42 pm | #27 | |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
Re: Yet another MK14 tape interface (ESP32).
Quote:
JS Jump to Subroutine JS pntr,destination which translates to Code:
LDI /destination-1 XPAH pntr LDI #destination-1 XPAL pntr XPPC pntr RET Return from Subroutine RET pntr |
|
19th Dec 2021, 3:58 pm | #28 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,115
|
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 ; Last edited by Phil__G; 19th Dec 2021 at 4:09 pm. |
19th Dec 2021, 4:45 pm | #29 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
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. |
20th Dec 2021, 10:14 am | #30 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
Re: Yet another MK14 tape interface (ESP32).
I wasn't aware of JS and RET
Sorry for the confusion! |
20th Dec 2021, 10:51 am | #31 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,115
|
Re: Yet another MK14 tape interface (ESP32).
|
20th Dec 2021, 2:33 pm | #32 |
Octode
Join Date: Apr 2018
Location: Newbury, Berkshire, UK.
Posts: 1,287
|
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.
|
27th Dec 2021, 9:53 pm | #33 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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 |
28th Dec 2021, 6:24 pm | #34 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
Re: Yet another MK14 tape interface (ESP32).
Thanks for the update and corrections - sounding good.
|
28th Dec 2021, 8:00 pm | #35 |
Octode
Join Date: Mar 2011
Location: North Yorkshire, UK.
Posts: 1,115
|
Re: Yet another MK14 tape interface (ESP32).
Trivial, but a copy & paste typo
Code:
TASK20 LDE ;Task20 is High byte of execution address |
28th Dec 2021, 9:22 pm | #36 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
Re: Yet another MK14 tape interface (ESP32).
Yes sorry, cut and paste typo. ; Task20 is Low byte of execution address
|
10th Apr 2022, 5:47 pm | #37 |
Tetrode
Join Date: Aug 2020
Location: Wallington, Greater London, UK.
Posts: 87
|
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. |
10th Apr 2022, 7:21 pm | #38 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
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? |
10th Apr 2022, 8:08 pm | #39 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,363
|
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.
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. |
10th Apr 2022, 8:20 pm | #40 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,556
|
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. |