andrew96

Anyway more has been discovered about the chips! they are NOT PAL16 chips, they appear to be a custom version of them for which there is no information on the internet!! they quite possibly have more internal loops back to the logic array as they seem to do far more than a standard PAL chip can accomplish! I am very happy I managed to get the lamp table into a GAL16v8 which works! but the resources for a character table as far as I can see are just not there!! they could be possible if the 2 unused flip flops could be fed back into the array, but this seems impossible due to the chips not having the 'node' or 'pinnode' commands (all outputs from the flip flops have to be connected to physical pins to be able to feed them back into the logic array). this is what leads me to believe the chips used were custom with the extra pinnodes and most likely custom software to use on designing them! I cannot see any other way of being able to manipulate the data in such ways necessary to produce all the output combinations, 192 for the character table possible values (yes its 64 x 3 in reality) and 24 for the lamp table (3 x 8 of which 8 are accessed) so 216 different combinations of output numbers PLUS 00 to reset it of course, that's a lot of data for one small PAL chip which I think a normal PAL or GAL chip could never handle! But I am happy with by modest 8 column lamp table! I think with the work John Parker has managed there is really no need for me to progress further as he has broken all this totally with 'adjustments' to the rom code! I have done what I set out to achieve as when I started no one had cracked the lamp tables for real machines! It has progressed so quickly that producing a real chip for real machines I set out to do at the beginning of the thread is now 'outdated'!

No I have not given up on the technical stuff! I find it too interesting!! As for the Mecca...... with the negative comments it was no longer fun! and you know the slogan... when the fun stops stop!

these chips are currently available new ( well different numbering but are the same) for around £1 yes I could go to a more complicated fpga, cpld etc but then that means the chip cost goes up, and also some pcb adapter needs to be made etc, I had my fingers burned on getting adapters made up for the fruit machine world in the past so not doing that again!! I learnt my lesson, just do things for myself! I was just eager to find out what they had done and if I could mimic something which I have succeeded on with lamps!! yay!! (well almost) I think I am nearly at my limits with what I can do ! even barcrest won't know anything about these now as there resources will be long gone! I am really on my own in new territory with this!! And I don't have lots of old original chr chips to play with!

If I use a sequence it has to distinguish between getting reset at #00 then getting #1a and going through the chr table one after the other....till the end #00, and also #00 for reset then #00 for lamp column 1 then #01 for lamp column 2 etc, now the lamp is NOT read in sequence in hyper viper, it reads 00, 01,01,01,04,04,04,09,09,09,10,10,10 in sequence lots of times before going out of sequence to read some again and then 31,24,19 which is why i used a table for that as the output numbers out don't change they certainly packed in variation!

yes red is sent to the chr chip, yellow (in hyper viper case) is the reply. challenge values are doubled up on so a simple table like for the lamps is a no go this is some of the challenge values doubled up on! (there may be more!) all reply different values to the first access of them! so distinguishing between them I cannot see will be easy with just logic and 2 flip flops! that's why I think barcrest started off with a 'seed' number which somehow all codes are derived from all dependant of the previous values answer!

Possibly just the lamp table is what I will only achieve. Most know how to over come the chr check and checksum, but very few can write code to put in the rom for the lamp table. so a chip with just a lamp table could be quite useful!

http://ee-classes.usc.edu/ee459/library/datasheets/16v8.pdf

I have 0 experience of using PAL /GAL chips so am making it up as I go along to fit what is needed I dabbled a few years back with a simple address in... data out table and one for a gals panic by again looking at the logic in / out then using wincupl to make one up! but as for doing anything like this with just simple logic.... no experience at all! I expect barcrest programmers used all the tricks in the book to squeeze it all in!!! I can't!! lol

I can see what you mean, but it is only logic gates in these chips, logic gates and 8 flip flops, it cannot process like a microprocessor, so I can only use what its input is to generate a output, Yes a sequence out would be good, but I don't have the luxury of using flip flops as a 0 to 64 counter as only have 2 left! even now with the first #00 in the reply is #00 , so thought if I use the inverted flip flop outputs and then AND them, this will produce a 1 so the next in the table for column 1 will be #80 when #00 is re-applied! brill I thought! but wincupl wont let me use a 6 input a AND gate on the flip flops /Q outputs! I have for at least 2 hours been trying to find a way around that simple step!!!! I am not entirely sure there is enough resources to hold a 64 character stream, no one knows but it is presumed there is some key and with flip flips and logic it manages to come up with a pattern of numbers in the right order. If there is a initial seed for this no one knows it!

At the moment with the lamp table I have been lucky the the reset value #00 sent to the chip returns #00 which is also the first lamp column value! I have to work out now the first #00 write to it gives the reset #00 then the next #00 onwards gives the lamp table value. then in the chr table there are 2 writes of several numbers the same, one being #1a so need to distinguish that too, I had thought of counters but only have 2 flip flops left as had to use 6 for the output latches! they crammed a awful lot into that small chip that has little resources!! so not a easy way forward..... I am not a expert by any means on programmable logic arrays! certainly going to take some time I think

john, did you know this thread has has 1.2k views!!

yeah the idea hopefully is to add in a character table now I have got to this stage! I thought I would start with the lamp table first as this proves the code I have so far works and can be seen very visually! If someone has a patched out character check and checksum then the correct lamp table in a chip is a easy option, but if you can perfect your patching program then I am just doing this for my amusement which is what I started out to do!

Well after a lot of head scratching I eventually discovered the PAL chip is being accessed slightly differently for the Yamaha card! after logging the differences with the oscilloscope then modifying the code I now have it working on the Yamaha card! it also still works on the basic card too!! All lamps in the correct place on the rig!! progress!!! that has taken some hours to find!!!

People will like your solution better!! no chip needed!!!

I have also come across a older rom which has no #802 / #803 references for the lamp table, so it would look like different machines do things differently, to me it would seem one patch doesn't do it all!

well this certainly proves the lamp table does not change depending on if it has a sound chip or not! so I think now there is some conflict with my chr chip and the yamaha sound chip!

Yes sorry about that, been doing so much messing I forgot I tried different roms and had not put the dip switches back again! and of course once posted I could not delete the post! I will run this in the real hyper viper club tomorrow! but I now cannot see why it would not work correctly!! I think it is this causing the problems i was having I found writing to anything in the range #800 to #8FF would access the chr chip, so I think that's also where the Yamaha sound access would be too, well that's what I think!

amazing work!!!!!

AND works too on the yamaha sound card too!!!

oops!!!!!! MY BAD!!! I had moved the dip switches on the mpu4 to try another rom and had not put them back!!!!! not they are back in the right place the hacked rom with NO chr chip works on the non basic ROM card

I have tried it on both the rom card and the yamaha sound card, on both the correct lamps do light! (I know the lamp sequence off by heart now) but on real hardware it doesn't like it!! ILLEGAL OPTION!

oh my word!!!!! this is great!! I will try this rom back on real hardware on the 2 cards and see what happens!!

Thankyou thankyou! I am going through what you have done, yes in the hyper viper rom I am using I have the chr check and checksum bypassed, so it never looks for the chr check on the security chip. Really coincidental I have discovered hyper viper club (mine) uses exactly the same security chip as Andy Capp II : The Great Escape used in the makechr.pdf ! when the real security chip is used it writes and reads the same 3 times before moving on to the next... mame has position 1 as #74 so the cpu writes 01 to the chip, read it gets #F2 then it writes 01 again, then the read is #7A then it writes 01 a third time and the read is then #F6 If you 'AND' them all together you get #70 brill! thats how it does it you think!!! BUT then you look at the next in the table! mame #40, result #00 so nope that's not it!! Now I can put in my table #74 the #40 and it works the same, the cpu still reads it 3 times but with mine it is the same value!, trying to work out a link between the 3 returned numbers the real chip gives and the table I uses to get it working some seem to work using that, some don't! just trying to find a relation between real values and fixed values that work! here are the other values

cheers, I have really tried! NO chip inserted the 1st and last columns (8th) are correct! you would expect this as they are #00 and that's what is present on the data lines with no chip! so location #01 has #44 on the good NON Yamaha card! on that columns 1, 2, and 8 are then correct!!! on the Yamaha sound card columns 1 and 2 are correct, nothing more! so I go through the whole of the table (from #02 through to #7F) inserting #44, after hours and hours of plodding through the table #44 does nothing to move any lamps on any columns at all!. so am really really well and truly stuck! The fluke won't do like MFME and run through the code and be able to stop and display what's it's writing to address #802 ! so that's not a option! And MFME doesn't behave as in the real world with a Yamaha sound program card! MPU5 was easier than this!! So I have no idea how to resolve this!!

It appears the table changes with the addition of the Yamaha sound, it seems to be changing the lamp table mapping In the current lamp table only the first 2 table entry's change the first 2 columns, the rest change nothing!! this seems where MFME and the real world differ!