2nd Jun 2020, 5:28 pm | #261 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Wow looks good - those switches will be a bit small for you! If Sirius is happy with that then so am I.
|
2nd Jun 2020, 6:30 pm | #262 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Recreating the Bywood Scrumpi
Hello Phil - I am sad to say that there is no room in my life for a Scrumpi at this time but I appreciated the offer, thank you.
I will send another one of the Slothie PCBs to Tim and then he can swap it with you for one of your Scrumpi PCBs, if that will suit everybody? |
2nd Jun 2020, 6:42 pm | #263 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Sounds like a great option - Phil - there will be a PCB on its way to you if you PM your address - will be nice to have another MK14 user around here...
|
2nd Jun 2020, 7:19 pm | #264 |
Pentode
Join Date: Jul 2017
Location: Toulon, France
Posts: 239
|
Re: Recreating the Bywood Scrumpi
ok thanks friends I have good news for the scrumpi 2
and look at this article |
2nd Jun 2020, 7:52 pm | #265 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Quote:
But, it is for the SCRUMPI 3? I have been quietly working on reverse engineering that one as well. I have pretty much worked out the memory map (see below) and how the keyboard works and have built one for my SCRUMPI 1.5 (tm) breadboard to experiment with it. I have already added an EPROM socket to my SCRUMPI 1.5 and an extra socket to start looking at how we can make the minor changes to re-create that one first. I assume the PROM content is lost but, we have some information from the 3 and notes I have gathered to make something very similar. I expect he used a lot of KITBUG as it was published. I am still trying to get the circuit diagram for the VDU section from the journal article I bought (at significant cost) but Elsevier are giving me the runaround. But, I have started to work out the component list form the description - it is all rough notes at the moment but, I will tidy it up and publish what I have. Slothie seemed interested in helping reverse engineer that VDU as it could be used on an MK14 as well... Code:
Memory Map - from various sources: ---------------------------------- 0000-01FF - Monitor PROM (the first 48 bytes are visible in the screenshot in the manual pages...) 0000 3F C4 7F 36 C4 90 32 C4 0008 77 37 C4 DC 33 3F 01 53 0010 43 52 55 4D 50 49 20 33 0018 0D 04 C4 77 37 C4 DC 33 0020 3F 0D 43 4F 4D 4D 41 4E 0028 44 3F 20 04 C4 76 37 C4 Bywood Leaflet says PROM A holds: PUTVDU - which also does scrolling The software drivers only implement 32-127 and 01 CLS, 08 Backspace and 0D CR/LF GETKBD - scans keyboard and INT keys - branches to PUTVDU PUTTY and GETTY for TTYIN and TTYOUT connectors using Send B and Flag 110Baud 20mA - likley from KITBUG PUTART and GETART for serial I/O on the UART at 960 Baud (as the 15.625KHz clock is used) Article mentions 8 I/O routines listing these (ass: Display message Display accumulator as HEX number with or without trailing space... Read a hex number from the Keyboard. Four bytes from user stack to display a six digit number with SIGN. It says they can be entered by exchanging the program counter and pointer 3???? 0200-03FF - This must be the two empty slots on the right of the board... Monitor will detect if there is a PROM here if it reads a 00 at 0200 A disassembler PROM was also available from BYWOOD to expand the system. 0400-05FF 0600-07FF - User IO PROM routines (must be the right most PROM) I assume the displayed image from 77D0-77F8 represents a Ghost of this PROM as well... 77D0 E0 9C F3 C4 De? C9 00 C2 77D8 FD 31 90 87 3F C7 01 C4 77E0 77 37 35 CA FE C4 68 33 77E8 31 CA FF C5 01 3F C1 FF 77F0 E4 04 9C F7 C2 FF 31 33 77F8 C2 FE 35 37 C7 FF 90 DC Bywood leaflet says PROM B is: G xxxx - GO execute H xxxx - HEXDUMP I xxxx - IMPLANT displays the address and data , INT will move to following add =n (0-7) will store lowest two chars (a byte) ?n will provide the two characters (byte) back calculated as an offset from where you are > return to command mode - or hit reset... {{{ WHERE IS RESET BUTTON ? }}} L - Display the 8 label bytes Breakpoints use XPPC 3 C continue from where the last breakpoint was. 0800-09FF - RAM expansion Space as in the 8 chips to the left of the PROM area 0A00-0BFF 0C00-0CFF - Keyboard The User key is mapped to Bit 7 of the keyboard port at 0C00 Note that the INT key is mapped to SC/MP SENSE A (software decode as X'0D'.) 64 chars can be generated with the 19 keys 16 main + 3 shift so I am going to guess that 7 6 5 4 3210 (Lower four are a ROW but will be wired backwards...) User Alph1 Alph2 /Func 0-15 0 0 0 0 0000-1111(0-15) - this should be 30-3F i..e 0011 in upper The primary keys are 0-? (48-63, 30-3F) - (i.e. 0011) the review moans it should be 0-9,A-F! With Alph 1 I guess @-O (64-79, 40-4F) - (i.e. 0100) and Alph 2 I guess P-_ (80-95, 50-5F) - (i.e. 0101) then Func would do SP-/ (32-47, 20-2F) - (i.e. 0010) - could hw pull down a high on d4? which could be done by grounding one of the buffer chips held high... This bit trick is used on ASCII keyboards for setting lower case in the 60-7F range... This must be used with address lines to scan each key row with the shift keys just direct connected. We could do the Bit changing in software (which is implied by the article rather than using gates to make the keys do stuff - there are two chips next to it though perhaps one is a buffer as it is quite big.) 0D00-0DFF - UART... 16x Clock derived from 15.625KHz VDU making it 960 baud I am going to hazard a guess he uses the S68 STTY card decoding regime that places the signals on consequtive addresses using A2-A0 00 - READ DATA from UART 01 - READ STATUS from UART ( 5-7 unused, 4 DAV, 3 TBMT, 2 Over, 1 Framing Err, 0 Parity Err) 02 - WRITE DATA to UART 03 - WRITE PARAMS to UART (7 Parity, 6 Stop, 5/4 No of bits, 3 Even/Odd parity) 04 - RESET DAV line on UART (just access to the address data ignored) 0E00-0EFF - VDU RAM (from photo of manual) Memory mapped with 256 bytes 8 rows by 32 chars Bit 7 is inverse - Black on White chars A whole screen inversion can be done setting SC/MP Flag 0 to Logic 1. 0F00-0F7F - This will be the std INS registers I/O Ports 00-24 are control registers 00-07 - Clear BIT port A 08-0F - Clear BIT port B 10-17 - Set BIT port A 18-1F - Set BIT port B 20 Read/Write Port A 21 Read/Write Port B 22 Port A direction register D BUS (ACC) to ODA (1 = Output, 0 = Input) 23 Port B direction register D BUS (ACC) to ODB (1 = Output, 0 = Input) 23 Port B Mode Definition Reg D BUS (ACC) to MDR 7 6 5 4-0 (Port B Bit 7 Input, Bit 6 - Output to use this mode) x x 0 xxxxx - BASIC I/O x 0 1 xxxxx - STROBED INPUT 0 1 1 xxxxx - STROBED OUTPUT 1 1 1 xxxxx - STROBED OUTPUT WITH TRI-STATE 25-7F undefined 0F80-0FFF - 128Bytes of RAM on the I/O chip 64 for User, 32 User Stack, 8 Bytes for Labels (I assume for the =n function in the monitor for calculating offsets) and finally 8 bytes for the Monitor The picture in the review shows: SCRUMPI 3 STATUS DUMP P3 P2 P1 EX ST AC 0000 0000 0000 00 30 00 0FC8 F4 03 DC 0B 8B C4 8B 34 0FD0 FC 4A 74 8B 0F 84 87 F0 0FD8 D7 0B F4 0F 59 B6 FB D5 COMMAND ? ^ 0FE0-0FEF - So I guess (from another comment that the user stack is shown - he says 32 bytes but only 24 are visible and he has likely moved the memory pointer?) So labels 0FF0-0FF7 ??? Guess: If he based the Monitor on Kitbug (likely as he retains the TTY code and method for compatability): Top bytes are used by ROM monitor for register store for GO FF9 P1 High FFA P1 Low FFB P2 High FFC P3 Low FFD A FFE E FFF S |
|
2nd Jun 2020, 9:28 pm | #266 |
Pentode
Join Date: Jul 2017
Location: Toulon, France
Posts: 239
|
Re: Recreating the Bywood Scrumpi
great work have recognize the professional really impressed
in bywood ads a rom and sold as vdubug for the s68 can be it took information. for power supply I ordered power supply SRW-65-4001 Chassis mount. I followed marc. I would modify for -7v and -9v. https://www.curiousmarc.com/computin...microprocessor I also work on an eprom programmer mm5204 |
5th Jun 2020, 10:30 pm | #267 |
Pentode
Join Date: Jul 2017
Location: Toulon, France
Posts: 239
|
Re: Recreating the Bywood Scrumpi
hello
an interesting article on the scrumpi 2 |
5th Jun 2020, 10:56 pm | #268 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
|
6th Jun 2020, 8:42 pm | #269 |
Pentode
Join Date: Jul 2017
Location: Toulon, France
Posts: 239
|
Re: Recreating the Bywood Scrumpi
salu tim
yes well seen can be KITBUG or VDUBUG was proposed power supply was forecast in -7v and -12v the Eprom a 5204 I also work on a programmer of 1702 and 5204 |
13th Jun 2020, 9:50 pm | #270 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Well I received the Board from Phil (Thanks) so set about building it and a suitable PSU.
Struggled to work out why the PSU board started smoking (not connected don't panic)... I will leave finding the short as an exercise for the reader. I actually could not work it out at first and unsoldered half the bridge rectifier... Anyway all tests seem to indicate it would work with IC2,3 and 4 in I could generate reset, single step and slow pulse running. D7 with RUN/HALT down is held HIGH and can be pulled low by the switch etc. All the pins on IC1 socket test as correct and I get a rock stable +5v and -7.01v from the PSU. So I plugged in IC1 and all others except the Memory. On Power on all the data lines are lit but no address lines (I have only wired up two as the in line resistors on the LED's are a bit fiddly to make...) anyway RESET does not create address one. D0-D5 are 5v high but, D6 and D7 look like barely 2v. No clock signal on the X1 line from the capacitor either. Anyway 40 odd mins of head scratching and probing seems to have achieved little - then there is a 5v or so oscillation on pin 40 and pin20 - IC1 gets very hot and so do the two regulators. Seems it may be game over for this chip... maybe it was faulty anyway. PSU and all other chips test fine once IC1 is removed. So I will check the wiring very carefully. It is of course complicated by the need to have made a switch board as I did not have any of the little mini PCB switches that would fit. Maybe I need to order a few more SC/MP chips - that is assuming they are not SC/MP II that have been skimmed and reprinted... in which case I could be burning out good ones of those in pursuit of the SCRUMPI. |
13th Jun 2020, 9:58 pm | #271 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Recreating the Bywood Scrumpi
Was it one of the screw heads? (The short)?
I doubt that anyone would rebrand SC/MP IIs as SC/MP Is because the IIs are themselves quite valuable. It would make more sense to rebrand an ultra common 40-pin DIP IC of any sort, after all if you are doing something like that the last thing you care about is whether it will actually work. |
13th Jun 2020, 10:09 pm | #272 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Nope - keep looking
Quote:
|
|
13th Jun 2020, 10:14 pm | #273 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Recreating the Bywood Scrumpi
Bl**dy H*ll, all the tracks are shorted together at the end nearest the camera! In what world would that be a sensible thing to do? Where did you find that stripboard?
|
13th Jun 2020, 10:16 pm | #274 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Bingo... in my box of stock which dates back from the 80's in this case - was just the first one off the stack... I even ran some wet and dry over it as it was a bit tarnished. Just checked the last two in the packet are not like that.
|
13th Jun 2020, 10:18 pm | #275 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Actually in this case I just cut some holes in front of the electronics and it is all one big ground plane now... seems pretty safe way to go.
|
14th Jun 2020, 7:29 am | #276 |
Octode
Join Date: Mar 2020
Location: Kitchener, Ontario, Canada
Posts: 1,297
|
Re: Recreating the Bywood Scrumpi
I was wondering if the sc/mp chip that Tim had problems with might be an ins8050 the nat semi version of the intel 8050 and not an sc/mp at all.
Mark |
14th Jun 2020, 9:41 am | #277 |
Dekatron
Join Date: Aug 2011
Location: Newcastle, Tyne and Wear, UK.
Posts: 11,575
|
Re: Recreating the Bywood Scrumpi
That's quite a good observation actually Mark, looking at Tim's last image in #271 I can't read the number on the IC but it is obviously a plastic rather than ceramic package. The only SC/MP I ICs I ever saw myself were in ceramic packages.
Googling INS8050 brings up a lot of hits for programmers which can programme those which implies that they have internal ROM, so obviously a different family of devices to the SC/MP - I assume they must be part of the same family as the Intel 8048/8049 etc. Tim had his prototype working didn't he, but that was with an SC/MP II fitted I think? |
14th Jun 2020, 2:02 pm | #278 | |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Quote:
That means I have a large number of unknown factory Mask programmed chips... I did say on other threads that this was an expensive hobby to make mistakes on. |
|
14th Jun 2020, 2:03 pm | #279 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
Yes my prototype used an SC/MP II.
|
14th Jun 2020, 2:14 pm | #280 |
Octode
Join Date: Mar 2019
Location: Barry, Vale of Glamorgan, Wales, UK.
Posts: 1,364
|
Re: Recreating the Bywood Scrumpi
I think in order to proceed I will hack this card to use the SC/MP II as I am unlikely to find an SC/MP - this will at least allow us to confirm the PCB should work without risking Phil's original Ceramic one initially and allow progression to a finished PCB that could take the switches and maybe has a few little tweaks to allow the SC/MP II hacks to be done easier for people interested in building one.
Or maybe just finish the SCRUMPI II card as that is more useful with its EPROM anyway. I will await the view of Phil. Finishing a SCRUMPI 1 card seems useful in case some SC/MP stock turns up. I am anxious to get onto the SCRUMPI 3 as its VDU looks like an interesting challenge... |