I can't find a list of all the devices/hardware the oric community have, I think it could be interessting to know all the oric hardware issues, ROM versions, ULA version etc.
For exemple, I have here with me 5 Oric ROM (3 Atmos and 2 One) and 5 ULA, 3 One/Atmos mainboard, and for each I have I have at least 2 or 3 different version (I have a 16K mainboard fitted with 64K, one issue 3, one issue 4) 2 versions of the 1 rom (from the marking point of view) same for the ULA.
Same here all my board have absolutly not the same hardware patches set on them, so I want to compile the AbsoluteOric1AtmosHardwareReworksForTheAmazingOricInFinalVersion!
If it put online a dedicated pages for this if there are people interested in filling it. I will make too a small basic program to calculate the CRC of the ROM. I will see too for the Microdisk/Jasmin, it could be interesting to inventory them too.
Hardware inventory
Re: Hardware inventory
I like this hardware inventory idea but for other reasons such as a potential source of spares and to keep almost a museum record of the hardware that was available on the Oric range.
People like Jon Haworth used to visit OUM meetings with a vast array of Oric hardware extensions such as the original Byte Drive 500.
Another chap brought his home made video camera which he demoed (Peter Bragg). All interesting hardware but most undocumented which is a great shame.
Now I admit some may not wish to advertise the fact they have a unique gadget or they have by now packed it all up in the attic. the Oric wiki also discloses some of the hardware but a separate site could be tremendous. Even if it also documented hardware that never saw the light of day such as the Phoenix boards.
People like Jon Haworth used to visit OUM meetings with a vast array of Oric hardware extensions such as the original Byte Drive 500.
Another chap brought his home made video camera which he demoed (Peter Bragg). All interesting hardware but most undocumented which is a great shame.
Now I admit some may not wish to advertise the fact they have a unique gadget or they have by now packed it all up in the attic. the Oric wiki also discloses some of the hardware but a separate site could be tremendous. Even if it also documented hardware that never saw the light of day such as the Phoenix boards.
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Hardware inventory
Uping this thread, what is may be the most important is to reference all the rework that was done on the Oric, some may have importances, especially when the problem that some people have with the Cumulus...
A discussion I had with metadata seems to show that some Oric that have a rework on Phi2 may have problems with the cumulus. So documenting all the existing rework could be really useful..
A discussion I had with metadata seems to show that some Oric that have a rework on Phi2 may have problems with the cumulus. So documenting all the existing rework could be really useful..
My Projects: Replic'Oric Project - StratoCumulus Project
Re: Hardware inventory
You mean the modifications in the service manual, here http://www.48katmos.freeuk.com/servman.pdf, or maybe some other?
This is interesting... Which one do you think may affect Cumulus?
This is interesting... Which one do you think may affect Cumulus?
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Hardware inventory
Other modification that are not part of the service manual, if you look at my (lost) atmos (photo here : http://forum.defence-force.org/viewtopic.php?f=23&t=919 ) there is a rework on the Phi2, some rework on the tape in line
My Projects: Replic'Oric Project - StratoCumulus Project
Re: Hardware inventory
Ah, I see. Is that the typical modification they made to allow an Oric to work with a Microdisc when sent for repair? I am just curious about what this modification did to the phase2 signal. And how this might affect cumulus (I imagine that it is related to the CumulusBUS trying to adjust/filter a signal that is already adjusted/filtered).
If you post some details, just for the record, that would be very nice.
If you post some details, just for the record, that would be very nice.
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Hardware inventory
From the photo, it seems only that this rework is to make the Phi2 signal stronger (the transistor will behave like a buffer in this case) but it could led to some problemes:
- The transistor could add some slight delay on Phi2 (I discuss about this with a friendly and it seems to be unlikely that the delay is noticeable, especialy at the 1Mhz clocking of the Oric)
- The rework on the tape_in seems to be to strength the signal to drive the transistor before the VIA, the tape is really unreliable on the Oric, especially at the "high" speed baudrate.. (I wonder if this rework have an impact on tap2cd)
- The transistor could add some slight delay on Phi2 (I discuss about this with a friendly and it seems to be unlikely that the delay is noticeable, especialy at the 1Mhz clocking of the Oric)
- The rework on the tape_in seems to be to strength the signal to drive the transistor before the VIA, the tape is really unreliable on the Oric, especially at the "high" speed baudrate.. (I wonder if this rework have an impact on tap2cd)
My Projects: Replic'Oric Project - StratoCumulus Project
-
- Squad Leader
- Posts: 774
- Joined: Sat May 21, 2011 7:21 pm
- Location: Between UK and France
- Contact:
Re: Hardware inventory
I have made a simple basic program (ok there is a bit of assembly inside) to calculate the CRC of the ROM (could work for jasmin and microdisc rom as well) I haven't tested it, can't do it at work
I try to made it as concise as possible to be type by a user. I'll post the code to get it back at home, but please if you want to try it, do it first on an emulator, I won't be responsible of crash or damaged Oric by using this software :p
Basic code:
Assembly one:
The CRC32 calculation was found On The Internet.. By the way be careful with x. It want to generate bad instruction opcode if you give him some invalid instruction text (try to add a lda (addr), it will generate a $B2, $00
BTW2: does someone already saw a 6502 assembler that accept such an instruction:
??
(the CRC code come from here: http://mdfs.net/Info/Comp/Comms/CRC32.htm )
Why I use CRC32 ? because Fabrice made a table of ROM version using CRC32 value, see here
I try to made it as concise as possible to be type by a user. I'll post the code to get it back at home, but please if you want to try it, do it first on an emulator, I won't be responsible of crash or damaged Oric by using this software :p
Basic code:
Code: Select all
100 REM Calculate memory CRC32
110 LOADADDR=#B800:REM May need to be changed...
111 ROM=0:REM 0 = Basic,1 = Microdisc,2 = Jasmin
112 ADDR=#C000
113 COUNT=#4000
120 CLS:PAPER 0:INK 7:PRINT"Copying data..."
121 READ NBD
122 FOR I=0 TO NBD-1
123 READ D
124 POKE (LOADADDR + I),D
125 NEXT I
130 PRINT"Source = "; ROM
131 PRINT"Start Addr = #"; RIGHT$(HEX$(ADDR),4)
132 PRINT"Count = "; COUNT
140 REM Set parameters
141 POKE LOADADDR,ROM:REM ROM Type at LOADADDR + 0
142 DOKE (LOADADDR+5),ADDR:REM Address at LOADADDR + 5
143 DOKE (LOADADDR+7),COUNT:REM Byte Count at LOADADDR + 7
150 PRINT"Calculating CRC32..."
151 CALL (LOADADDR+9)
161 FOR I = 0 TO 3
162 LET CRC(I) = PEEK(LOADADDR+1+I)
163 NEXT
170 PRINT"Calculated CRC32 = #";
171 FOR I = 3 TO 0 STEP -1:PRINT RIGHT$(HEX$(CRC(I)),2);" ";:NEXT
172 PRINT"":PRINT""
1000 REM Assembly CRC program
1001 DATA 164
1010 DATA #00,#FF,#FF,#FF,#FF,#00,#00,#00,#00,#A5,#00,#48
1010 DATA #00,#00,#00,#00,#00,#00,#00,#00,#00,#A5,#00,#48
1011 DATA #A5,#01,#48,#AD,#05,#B8,#85,#00,#AD,#06,#B8,#85,#01,#A9,#01,#CD
1012 DATA #00,#B8,#D0,#08,#AD,#14,#03,#29,#FD,#8D,#14,#03,#A9,#02,#CD,#00
1013 DATA #B8,#D0,#05,#A9,#01,#8D,#FB,#03,#A2,#08,#A0,#00,#B1,#00,#4D,#01
1014 DATA #B8,#4E,#04,#B8,#6E,#03,#B8,#6E,#02,#B8,#6A,#90,#1C,#A8,#AD,#04
1015 DATA #B8,#49,#ED,#8D,#04,#B8,#AD,#03,#B8,#49,#B8,#8D,#03,#B8,#AD,#02
1016 DATA #B8,#49,#83,#8D,#02,#B8,#98,#49,#20,#CA,#D0,#D5,#E6,#00,#D0,#02
1017 DATA #E6,#01,#8D,#01,#B8,#AD,#07,#B8,#D0,#03,#CE,#08,#B8,#CE,#07,#B8
1018 DATA #D0,#B6,#AD,#08,#B8,#D0,#B1,#A2,#04,#BD,#01,#B8,#49,#FF,#9D,#01
1019 DATA #B8,#CA,#D0,#F5,#AD,#14,#03,#49,#02,#8D,#14,#03,#A9,#00,#8D,#FB
1020 DATA #03,#68,#85,#01,#68,#85,#00,#60
Code: Select all
; Calculating ZIP CRC-32 in 6502
; ==============================
; Calculate a ZIP 32-bit CRC from data in memory. This code is as
; tight and as fast as it can be, moving as much code out of inner
; loops as possible.
;
; On entry, crc..crc+3 = incoming CRC
; addr..addr+1 => start address of data
; num..num+1 = number of bytes
; On exit, crc..crc+3 = updated CRC
; addr..addr+1 => end of data+1
; num..num+1 = 0
;
; Multiple passes over data in memory can be made to update the CRC.
; For ZIP, initial CRC must be $FFFFFFFF, and the final CRC must
; be eored with $FFFFFFFF before being stored in the ZIP file.
;
; Extra CRC optimisation by Mike Cook, extra loop optimisation by JGH.
; Total 63 bytes.
;
*=$0000
addr:
*=$B800
runmode:
.byt $00
crc:
.byt $FF, $FF, $FF, $FF
addrin:
.byt $00, $00
num:
.byt $00, $00
; Save $00 and $01s
lda addr
pha
lda addr+1
pha
lda addrin
sta addr
lda addrin+1
sta addr+1
; Now check runmode to correct ROM to checksum
lda #1
cmp runmode
bne test_jasmin
; Ask for MD switch
lda $0314
and #$FD ; Disable BasicROM
sta $0314
test_jasmin
lda #2
cmp runmode
bne crc32
; Jasmin
lda #$01 ; Disable BASIC rom
sta $03FB
crc32:
_bytelp:
ldx #8 ; Prepare to rotate CRC 8 bits
ldy #0
;lda (addr-8 AND $FF,X) ; Fetch byte from memory
lda (addr),y ; Fetch byte from memory
; The following code updates the CRC with the byte in A ---------+
; If used in isolation, requires ldx #8 here |
eor crc+0 ; eor byte into CRC bottom byte |
_rotlp: ; |
lsr crc+3 ; |
ror crc+2 ; Rotate CRC clearing bit 31 |
ror crc+1 ; |
ror ; |
bcc _clear ; b0 was zero |
tay ; Hold CRC low byte in Y for a bit |
lda crc+3 ; |
eor #$ED ; |
sta crc+3 ; CRC=CRC eor $EDB88320, ZIP polynomic
lda crc+2 ; |
eor #$B8 ; |
sta crc+2 ; |
lda crc+1 ; |
eor #$83 ; |
sta crc+1 ; |
tya ; |
eor #$20 ; Get CRC low byte back into A |
_clear: ; |
dex ; |
bne _rotlp ; Loop for 8 bits |
; If used in isolation, requires sta crc+0 here |
; ---------------------------------------------------------------+
inc addr
bne _next
inc addr+1 ; Step to next byte
_next:
sta crc+0 ; Store CRC low byte
; Now do a 16-bit decrement
lda num+0
bne _skip ; num.lo<>0, not wrapping from 00 to FF
dec num+1 ; Wrapping from 00 to FF, dec. high byte
_skip:
dec num+0
bne _bytelp ; Dec. low byte, loop until num.lo=0
lda num+1
bne _bytelp ; Loop until num=0
ldx #3
_neg:
lda crc,x
eor #$ff
sta crc,x
dex
bne _neg
; Revert MD
lda $0314 ; Just change
ora #2
sta $0314
; revert Jasmin
lda #$00 ; Enable BASIC rom
sta $03FB
;restore $00, $01
pla
sta addr+1
pla
sta addr
rts
BTW2: does someone already saw a 6502 assembler that accept such an instruction:
Code: Select all
LDX #8 :\ Prepare to rotate CRC 8 bits
LDA (addr-8 AND &FF,X) :\ Fetch byte from memory
(the CRC code come from here: http://mdfs.net/Info/Comp/Comms/CRC32.htm )
Why I use CRC32 ? because Fabrice made a table of ROM version using CRC32 value, see here
My Projects: Replic'Oric Project - StratoCumulus Project