Recent Posts

Pages: [1] 2 3 4 5 6 ... 10 Next
1
General Chat / Re: Birdemic - possibly the best movie ever made...
« Last post by timb on Today at 03:31:11 AM »
Indians do it right (endhiran)



So... It’s basically Terminator: Rise of Mumbai?
2
General Chat / Re: They've borked my homepage and screw up
« Last post by tpowell1830 on Today at 03:28:09 AM »


:palm: don't do business with GoDaddy. There are many, many more reputable and reliable registrars out there.



Would you go a little further and explain why you say that about GoDaddy? I have had services with them for 15 years with very few problems and problems resolved very quickly when they do occur.
3
Thanks David.
The target accuracy is %0.25+2digits.

That is only 400 counts at most making 20,000 counts overkill.  There are many more 12 bit ADC options than 16 bit ADC options.

Quote
I was also thinking RMS to DC converters as they are low power too and will help with the accuracy.

You are better off sampling the signal and calculating the RMS from the standard deviation.  The RMS converters that I checked draw more than a suitable sampling ADC and have a long settling time so they have to be powered for much more than 2 out of 50 cycles.
4
Test Equipment / Re: Test Equipment Anonymous (TEA) group therapy thread
« Last post by Berni on Today at 03:23:56 AM »

Any references for the U1272A problems? I got a U1241C so I'm worried now  :-DD

Yep thats the EMC problem they have. I don't think the  U1241C is affected by it but i know that the entire U127x series is.

I have the OLED version U1273A that is affected and Keysight responded quickly by offering people replacement units once they revise the PCB to fix it or a U1281A as a replacement. I picked the later and indeed received one in the mail a few weeks later. :-+ Amazing support from Keysight
5
General Chat / Re: Are your backups up to date?
« Last post by Mr. Scram on Today at 03:22:53 AM »
Not at all :).
It is not the gun, it's the gunner...
Static files are subject to hashing when written, as they are static by nature they will be flagged by hash corruption. A total non issue.
Dynamic files are also subject to hashing but of no use as a direct integrity check. The parent application should maintain this integrity check. - self corruption is therefore a non issue providing multiple date/state copies exist. A total non issue.
Dynamic files and the issue of 'user' corruption / invalid or incorrect data entry or deletion or 'insert and other 'PBCAK' here' is managed by standard dynamic file methodology and also a far FAR longer TBO regime - (time before overwrite - if you are unfamiliar)
Dynamic files that are not self managed for data integrity are also subject to extended TBO. Depending on needs and pockets and regulations TBO can be up of 5 years or more (7 in a lot of cases in the UK)
Again, with my system and my regime I am 99.999999% happy and secure. It is a total NON issue.  Simply unnecessary.  :-+ .
What happens when you RAM goes corrupt and slowly corrupts data over time, which shows itself after a while when the errors built up to critical mass? All the garbage is copied perfectly down the line, again and again, and your last clean backups will be months or even years ago. Not testing anything is setting yourself up for failure. You're not the first and won't be the last. In the end, there has to be a monkey checking to see if the recovery process output lines up with the input.

Besides, anyone not nervous about his backups is complacent and will fall eventually  :box:
6
Hey guys, superb info and good food for thought. ! - really appreciated. What a super wealth of knowledge here :)
7
From what I am reading, guess you did not do slow changes with verify steps to see each part is working.

Eeeerr...  :-[  Noooo... I DID wire it all up with just the Qn connections disconnected and the memory select lines intact and it worked, but that doesn't really prove a lot I guess.  :-//

EDIT: Oh, I made the modifications to the 138 IO manager and it all worked fine there too, before building the rest of the MMU.

Note that with all ROM the Z80 STACK is not working.

The Z80 boot software should be able to start and send a message to serial even with out STACK working.

Yes, that did concern me a little when I was modifying the boot code for the ROM.  At startup, there's an army of EQUates and DSs reserving space for variables, but they're little more than labels the assembler uses for memory addresses to store values, so with an all-ROM memory they shouldn't cause any problems, right?

After the EQU's and DSs, at the start of the ROM effectively,  the code does this:

Code: [Select]
;------------------------------------------------------------------------------
;                         START OF MONITOR ROM
;------------------------------------------------------------------------------
MON .ORG $0000 ; MONITOR ROM RESET VECTOR
;------------------------------------------------------------------------------
; Reset
;------------------------------------------------------------------------------
RST00 DI ; Disable INTerrupts
JP MINIT ; Initialize Hardware and go

So it jumps to MINIT, which does this:

Code: [Select]
MINIT:
; Initialise MMU
LD C,MMU_IO ; Set C to IO port of MMU
LD A,$8F ; MMU disabled, Page 0 = Bank 0F
OUT (C),A
LD A,$91 ; MMU disabled, Page 1 = Bank 01
OUT (C),A
LD A,$A2 ; MMU disabled, Page 2 = Bank 02
OUT (C),A
LD A,$33 ; MMU enabled, Page 3 = Bank 03
OUT (C),A
LD A,$3 ; Set MMU_Lock byte so that Areas 0 and 1 are locked
LD (MMU_Lock),A ; from inadvertant re-mapping by the BANK command

LD    SP,MSTACK ; Set the Stack Pointer
LD HL,serABuf ; Set up Serial A buffer
LD (serAInPtr),HL ; with In and Read pointers
LD (serARdPtr),HL
LD HL,serBBuf ; Ditto for Serial B
LD (serBInPtr),HL
LD (serBRdPtr),HL
XOR A ; 0 to accumulator
LD (serABufUsed),A ; Set both buffer sizes to zero
LD (serBBufUsed),A

So the first commands to execute, aside from the initial JP, are to set up the MMU and memory space, so the rest of the monitor code will run normally (and starts by setting up the stack area in a newly-assigned RAM bank.)  That's the idea, anyway.

Is that all okay to run without a stack?

Now if the MAD Software creator happened to write some code.
The code could write some values to the 670 and let you test the 670
Even with out the STACK working a JP will work.
At boot Z80 A14 & A15 = 0
If boot code jumps to the different areas what is on A14 & A15 will change

So code is running in area 0
do a jump where A14 & A15 change to area 1 with the lower bits set for instruction after the jump

With the boot code showing in all four areas, the Z80 could jump between the areas and stay in that area a while by doing a loop.

While looping you could output a message to serial.
The Z80 could try to write to memory & read memory.
Note that the ROM write has a software safety lock so even with ROM's WR pin connected, Rom should be un-changed.

Okay, sounds like a plan.  :-+

Crap meter should read close to same value for same voltage.
If you measure USB Voltage with crap meter then you should get very close to same value every where for 5v.

Yeah, I'm not sure about the issue there.  If there really is only 4.2V at the 670, that could be a problem.  I'll look into it (along with the software edits you've mentioned) later this week when I have some time. Thanks. :)
8
General Chat / Re: Help! PC 'lost' contents of hard drive
« Last post by Mr. Scram on Today at 03:15:42 AM »
If you care about the data, make sure you don't use the disk anymore. Any file system operations can worsen the damage. Ideally you want to make a bit for bit copy of the drive, and use the copy for recovery attempts.
9
General Chat / Re: Are your backups up to date?
« Last post by Freelander on Today at 03:13:13 AM »

Quote
Having many copies of the original copy doesn't protect you from a lot of failure modes. You really do need to test whether you can recover relevant files from your backups on a regular basis. If you don't test, you don't know what you have. Your stacks of copies could be full of perfect files full of perfect garbage.
Not at all :).
It is not the gun, it's the gunner...
Static files are subject to hashing when written, as they are static by nature they will be flagged by hash corruption. A total non issue.
Dynamic files are also subject to hashing but of no use as a direct integrity check. The parent application should maintain this integrity check. - self corruption is therefore a non issue providing multiple date/state copies exist. A total non issue.
Dynamic files and the issue of 'user' corruption / invalid or incorrect data entry or deletion or 'insert and other 'PBCAK' here' is managed by standard dynamic file methodology and also a far FAR longer TBO regime - (time before overwrite - if you are unfamiliar)
Dynamic files that are not self managed for data integrity are also subject to extended TBO. Depending on needs and pockets and regulations TBO can be up of 5 years or more (7 in a lot of cases in the UK)
Again, with my system and my regime I am 99.999999% happy and secure. It is a total NON issue.  Simply unnecessary.  :-+ .
10
Anyone having issue with the code provided above?  I tried it, got an error about using the code in combination with other offers (I had only the scope in my cart), and then it messed up the pricing on my order (added $250 to the previous total).  I had to abandon the cart.  I'm waiting for Friday after Thanksgiving to contact Tequipment sales.
PM sent (this one is always valid).  ;)
Pages: [1] 2 3 4 5 6 ... 10 Next