1. This forum section is a read-only archive which contains old newsgroup posts. If you wish to post a query, please do so in one of our main forum sections (here). This way you will get a faster, better response from the members on Motherboard Point.

talking to CTK 571 synthesizer

Discussion in 'PC Hardware' started by Allan Adler, Oct 31, 2007.

  1. Allan Adler

    Arno Wagner Guest

    Well, I have almost no experience with assembler on the PC.
    But it seems to me that reading von video memory need not produce
    what was in there. Or you are writing from a different area than you
    think. I would advise you to try the following:

    1.) write a pattern to main RAM, 4 Chars or so should be enough
    2.) Read it and output it to the screen to make sure it is there
    3.) Write this to disk

    If this still does not work, then my guess would be bad addressing.

    Arno Wagner, Nov 19, 2007
    1. Advertisements

  2. Allan Adler

    Allan Adler Guest

    Let me make sure I understand what you are saying:
    (a) I read a memory location M.
    (b) The location M contains a byte B.
    (c) The read tells me M contains a byte C.
    (d) It is possible that B does not equal C.

    How is that possible?
    Notice the line
    call abc
    at the beginning of the program. The subroutine abc is one that I wrote,
    modelled on the one in Part I of Krishnakumar's article, "Writing your
    own toy OS". It writes 128 a's, b's and c's (all with blue background)
    to the screen by using mov commands to write directly to the screen
    buffer. It works. So, in effect, I've already done what you suggested.
    Also, using the routines "say" and "wout", which I scavenged from
    the lilo source and which use interrupt 10h to write to the screen,
    I've been successful in writing diagnostics to the screen. What isn't
    working is interrupt 13h in reads and writes between the upper memory
    area (including the screen buffer) and the floppy diskette. However, when
    I address the lower memory (in effect by writing above 1 MB and wrapping
    around to low memory) then stuff other than FF's appears on the floppy.

    It's quite possible that I am addressing the memory incorrectly, as you
    say. I tried to write a program that reads the diskette and writes to the
    screen and so far it hasn't worked. I now know how Linux maps the diskette
    to a file via /dev/fd0 so in principle writing a bunch of blue D's to the
    diskette should make it possible, via a disk read to the screen buffer,
    to make the D's show up on the screen. But so far it doesn't work.
    Allan Adler, Nov 19, 2007
    1. Advertisements

  3. Allan Adler

    Arno Wagner Guest

    If I understand correctly, you are reading screen memory. That
    is not ordinary RAM, but far more complex.
    No. You have written to screen memory. It may behave in unexpected
    ways. Repeate this with conventional RAM.

    Arno Wagner, Nov 20, 2007
  4. Allan Adler

    Allan Adler Guest

    OK, I'll try to read about the differences. Thanks for pointing that out.
    OK, I think I can do that. The main attraction of writing to screen
    memory is that I can see what happens, at last when I do it with moves
    to the address of the screen buffer. But what I can do instead is to
    write to another memory location, then move from that memory location
    to AX and then use wout to see the contents of AX as hex. And there
    are some improvements on that to try. At least wout works. Thanks
    for pointing out my error.
    Allan Adler, Nov 20, 2007
  5. Allan Adler

    Allan Adler Guest

    These 128 a's, 128 b's and 128 c's start in the upper left corner of the
    screen and fill most of the first five lines. I used int 0x10 with AH=2 to
    set the cursor position at the upper left corner of the screen. Then I used
    int 0x10 with AH=8 to get the character and its attribute at that cursor
    position into AX. Then I called AX to display AX in hex and, behold,
    4 A's in the first line were overwritten by 1F41. Thus, it successfully
    read the A (ascii 41h) with blue background (attribute 0x1F) and printed
    that information on the screen, So, that's some progress.

    Similarly, I moved the contents of memory location 0xC0000 into AX and
    called wout to display something like EF6F on the screen. So, that's
    progress with reading upper memory. Next I'll try moving location 0xB8000
    and displaying it with wout, and then I'll go back to experimenting with
    diskette reads and writes.

    I read about video memory and learned that some hardware implementations of
    it are dual ported, allowing reads and writes to overlap. So, I accept that
    it is more complicated. However, Frank Gilluwe's book, The Undocumented PC,
    recommends reading video memory to get better speed than repeatedly using
    certain interrupts. So, the problem with video memory might not be whether
    one can read it reliably. Maybe it is a timing problem of some kind that
    manifests when one tries to use the floppy drive.

    I wrote a program that calls int 13h with AH=3 repeatedly to copy "all"
    of memory (all 1 MB of it) to the floppy, starting with location 0x00000.
    It seems to succeed with lower parts of memory but eventually writes all FF's.
    There are two occurrences of the string "Hello, World!" in the sectors written
    to the floppy. There is a subroutine in the boot sector program that prints
    this message, but I don't actually call the subroutine. However, since the BIOS
    loads the boot sector into memory, it is right for at least one copy of the
    string "Hello, World!" to be found but I'm not sure why there are two (actually
    three, counting the boot sector).
    Allan Adler, Nov 24, 2007
  6. Allan Adler

    Allan Adler Guest

    I read the chapter on the use of the 8254 chip in the PC, especially
    timer 2. So, now I'm wondering whether there is any way to actually
    time how long it takes to read various places in memory. I don't think
    that will shed much light on the problem until I have actually examined
    the BIOS code for int 13h with AH=3, but I can't examine the BIOS code
    for int 13h with AH=3 due, apparently, to these timing problems.

    I tried another approach. I wrote a subroutine using
    to move memory locations 0xC0000 through 0xFFFFF to locations
    0x50000 through 0x8FFFF. (I've been under the impression that
    0x50000-0x8FFFF is part of ordinary RAM. Then I used dsk_do_rw
    repeatedly to write locations 0x50000 through 0x8FFFF to the floppy.
    The return codes show that the PC thinks it did the writes, but when
    I examined the floppy with dd and od under Linux, it showed only 0's
    outside the bootsector. I'm not sure yet whether it is the first part
    or the second part that didn't work, but one side effect of the present
    activity is that I'm getting better at getting the bootsector program to
    print legible diagnostics. So tomorrow I'll consider what kinds of
    diagnostics might tell me what exactly is happening when my program runs.

    It's possible that the combination
    suffers from similar timing problems. Maybe a more common sense way to think
    about this is the following:
    (1) int 13h, AH=3 was probably intended to facilitate copying files from
    one disk/diskette to another. Accordingly, it was probably written with
    the assumption that the parts of memory involved were ordinary RAM
    and the timing cycles for it designed accordingly.
    (2) ROM was probably assumed to be read mainly by the CPU reading instructions
    and not copied in blocks to other parts of ordinary RAM. In particular,
    ROM should probably be read one byte at a time and moved to a register.

    If that makes sense, then instead of wholesale copies such as rep followed
    by movsb I should move one byte or word at a time to a register and then move
    that byte to the place in RAM I am using. After that using dsk_do_rw to
    write from RAM to the floppy might work.

    Also, instead of trying to obtain all of 0xC0000-0xFFFFF, maybe I should
    first focus on just getting one sector's worth by the above methods. Even
    that would be more than I can do now and it would simplify the programming.

    More when I imagine I know more...
    Allan Adler, Nov 28, 2007
  7. Allan Adler

    Allan Adler Guest

    OK, I'm convinced that video memory is inherently weird. I implemented the
    code in part two of Krishnakumar's article, "Writing your own toy OS"
    and it ran fine. The code consists of a boot sector program that loads
    another program from sector 2 of track 0 to 0x5000 and jumps to it. The
    latter program calls int 10h to find the current cursor position and then
    writes the message, "Handling BIOS interrupts" with another call to
    int 10h. Then to reassure myself about my earlier attempts to write to
    0x50000 I changed the code in one place to get it load the sector 2 program
    there instead. It still ran fine. Then I added a line which moved location
    0xb8000 to ax and a line to move ax to location 0x501fe and then called
    int 13h to write the sector at 0x50000 to sector 3 of the floppy. That
    worked fine. It was easy to compare sectors 2 and 3 of the floppy to
    see that they were identical except for the last word, which was 0xaa55
    in sector 2 and was 0x0720 (a black blank from the screen) in sector 3.

    Then I eliminated the lines copying to and from ax and simply called
    int 13h to write a sector of screen to sector 3 and again to write a
    sector of 0xc0000 to sector 4 of the floppy. This produced the usual
    all FF's in sectors 3 and 4. What was remarkable was that, whereas in
    all the earlier experiments with this program from part 2 of Krishnakumar's
    article the message "Handling BIOS interrupts" had faithfully appeared
    after all the other activities were completed, this time a different
    message appeared. It read: "Stop trying to read the BIOS!!! -- God".

    OK, it didn't really say that. What it printed were 2 extended ascii
    characters (female symbol and smiley rectangular face) followed by

    Now that I can load separate programs to execute, I'm no longer
    constrained by having to get everything to fit into 512 bytes, which
    was starting to be a problem. So, maybe next time I'll have some
    BIOS fragments.
    Allan Adler, Dec 1, 2007
  8. Allan Adler

    Arno Wagner Guest

    Good. So your approach is sound.
    I think God prefers far cleaner ways to do things than using
    computers. At least I would be thinking that if I did believe in
    God. ;-)

    Hmm. Are you perchance reading the VGA BIOS instead of the system
    Looks good to me.

    Arno Wagner, Dec 4, 2007
  9. Allan Adler

    Allan Adler Guest

    So it seems, at least if I only move one word.

    Gilluwe's book has a discussion on p.41 on how to determine the kinds of
    wait loops to use before accessing a device a second time. I'll read that
    tomorrow and see if it helps.

    Rod Pemberton pointed out to me a 512 byte bootsector operating system and
    kernel, which I downloaded. It is called 512DevOS 0.01. I've studied the
    source code and, although I don't want to use it, it should be easy to
    imitate. I plan to put the imitation in sector two of the floppy and have
    the bootsector load it and execute it. That will give me a kind of shell
    to work with that will respond to some simple commands. Presently, if I
    want to find out the effects of one of my crackpot ideas, I have to reboot
    the computer and execute dd and od from Linux to see what happened to the
    floppy. I'd like to give myself the capability of finding out what happened
    without rebooting into Linux. At the very least, it should be possible to
    implement some simple versions of PEEK and POKE and, as I find out more
    about what is going on, I can add to them.
    I'm an atheist myself.
    I don't think so.
    Still no fragments, but still making slow progress...

    I took apart an old mouse to get its opto-isolators in case I need to
    build a break-out box for the game port. I haven't removed them from
    the printed circuit board. Right now I'm rather intensely studying the
    printed circuit board to find out exactly how the mouse works, just in
    case there is a net advantage to leaving the opto-isolators where they are.
    One obvious advantage is that they are already perfectly placed relatively
    to each other. Each opto-isolator pair looks like a TV set, with a slightly
    recessed disk on one face and a slight bulge on the opposite face. The bottom
    face has three coplanar leads. One member of the pair is transparent. I think
    it is the transmitter. It seems to transmit from the bulge. The other member
    of the pair is black. It seems to receive through the recessed disk. If you
    know where I can find a data sheet for an opto-isolator pair fitting this
    description, please let me know.

    The mouse has a quadrature encoder IC in a 16-pin dual in line package.
    It has the marking EICI127400. I haven't been able to find any data sheets
    for it.

    Also, a rotary encoder for its track wheel. It has no markings but is
    turned by the hexagonal head of the axle of the track wheel, which fits
    perfectly the hexagonal hole in the center of the rotary encoder. The metal
    frame of the encoder has a kind of spout that fits into alternating radial
    valleys on one side of the encoder cylinder and moves slightly back and forth
    as it goes over the hills. It has three leads going down from it. I don't
    know where to find a data sheet for a device fitting this description.
    Allan Adler, Dec 4, 2007
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.